[OT:usage of uml]

ruby-talk
1

Hi All,

   I have just started to learn about Agile development and was told that in
Agile very less focus is given to documentation and usage of UML related
things is very less. Is it that its not used at all by most Agile developers
and most of the focus is on Test Driven Development. If code generation is
accompanied along with the tool being used for UML do people in agile go for
UML usage. This is the case I have seen in Java world using UML extensively.
As in Agile, time is a factor they dont get into that much details of UML.
So I was wondering how to gauge how much important UML is to Agile world.

  I know this is OT but Ruby and Rails goes hand in hand with Agile so I
have posted in both the groups so that I can get to know from people who
really practise Agile.

regards
Gaurav

2

gaurav bagga wrote:

  I have just started to learn about Agile development and was told that in
Agile very less focus is given to documentation and usage of UML related
things is very less. Is it that its not used at all by most Agile
developers
and most of the focus is on Test Driven Development. If code generation is
accompanied along with the tool being used for UML do people in agile go
for
UML usage. This is the case I have seen in Java world using UML
extensively.
As in Agile, time is a factor they dont get into that much details of UML.
So I was wondering how to gauge how much important UML is to Agile world.

There are more uses to UML than code generation (which I haven't seen
used yet actually.)

For certain problems, it's useful to have dedicated analysts or
high-level designers (can as well be one person) if the problem domain
being modelled is one the developer team has little expertise in - if
this person isn't a developer, UML is a standardised way for him to
communicate his work to the team members that are. Also if the model has
to be represented / manipulated using multiple languages (DDL for a
RDBMS, and multiple clients on that database in different programming
language), it might make sense to use UML as a lingua franca for the
reference representation of the model - of course, if all developers
have basic skill in one of those languages, you might use the model
implementation in it for this purpose.

Another reason I see behind UML-bashing by the agile crowd is that they
are people that don't have the brain arrangement (this I don't mean as
an offensive statement) to process the diagrams as efficiently as they
would see the actual code. For people with a degree of visually-oriented
thinking, a UML diagram can be a good tool to organise your thoughts on
a problem. I personally find (high-level) activity diagrams or sequence
diagrams easier to comprehend than code across three files.

For purposes of maintainability, UML is a more terse documentation
artefact for some views of a system than source code documentation.

On the whole, I'd say UML still is a valid tool for agile development.
You're likely to use only high-level variants - UML that is on a level
detailed enough to be used for code generation wouldn't be created up
front, maybe as a documentation artefact if that is required. It's also
still useful as a means of communicating a notion if you find you can
create and comprehend it as fast as or faster than other methods - a
unit test replacing a nontrivial sequence diagram might be much more
verbose, for example, if of more value on its own

David Vallner

3

Hi,

  I use UML with Ruby, partially because I still consider myself "new" to OO
programming concepts. UML and CRC cards help me wrap my mind around my
domain model. I more commonly use it when doing Rails, than when doing just
plain Ruby, because some Ruby classes are harder to model with it, but it is
wonderful for modeling relational database information. I don't often use
code generation, partially because my UML tool of choice has bad/no Ruby
support, and also because I still am learning this language, and I want to
know what to do, and why I do it. Our team does believe in Agile and XP
design concepts, so we do a lot of testing, and speccing, which we feel
better documents our code than UML. But when we are first starting a new
web application, with lots of DB tables, we fire up ArgoUML, and start
planning it out. UML is really good in aglie programming when you are first
starting, but then your tests, your specs and your code should start
becoming your documentation. When you use it, you will probably only use
class diagrams, and maybe use case diagrams (XP is worked into UML, just in
a bass-ackwards way), and you probably won't use the entire spec either.
UML is good for Agile design, but it really is a personal preference,
depending on (like David said) how you learn/comprehend things. Hope that
helped.

Chris

···

On 10/20/06, gaurav bagga <gaurav.v.bagga@gmail.com> wrote:

Hi All,

   I have just started to learn about Agile development and was told that
in
Agile very less focus is given to documentation and usage of UML related
things is very less. Is it that its not used at all by most Agile
developers
and most of the focus is on Test Driven Development. If code generation is
accompanied along with the tool being used for UML do people in agile go
for
UML usage. This is the case I have seen in Java world using UML
extensively.
As in Agile, time is a factor they dont get into that much details of UML.
So I was wondering how to gauge how much important UML is to Agile world.

  I know this is OT but Ruby and Rails goes hand in hand with Agile so I
have posted in both the groups so that I can get to know from people who
really practise Agile.

regards
Gaurav

--
Chris Carter
concentrationstudios.com
brynmawrcs.com

4

I know the basics of UML and try to follow it as best as I can.
You really have to use it to be able to learn it and apply it
quickly.

My personal preference still goes to using UML with a pencil
and paper; especially when staring a project. Using a modeler
just discourages me, because I know Ruby would be much faster.
It is nice to have your model abstracted from the code, in
case you decide to implement in a different language at a
later stage.

Agile methods and modeling can mix; you just have to find the
right balance.

My favorite resource is:

  http://www.agilemodeling.com

Cheers,

Emiel van de Laar

···

* gaurav bagga (gaurav.v.bagga@gmail.com) wrote:

Hi All,

  I have just started to learn about Agile development and was told that in
Agile very less focus is given to documentation and usage of UML related
things is very less. Is it that its not used at all by most Agile developers
and most of the focus is on Test Driven Development. If code generation is
accompanied along with the tool being used for UML do people in agile go for
UML usage. This is the case I have seen in Java world using UML extensively.
As in Agile, time is a factor they dont get into that much details of UML.
So I was wondering how to gauge how much important UML is to Agile world.

I know this is OT but Ruby and Rails goes hand in hand with Agile so I
have posted in both the groups so that I can get to know from people who
really practise Agile.

5

David Vallner wrote:

For purposes of maintainability, UML is a more terse documentation
artefact for some views of a system than source code documentation.

It would be interesting if it were possible to generate UML from ruby source and/or execution traces. Like RDoc's use of graphviz/dot to generate class hierarchy diagrams, but more comprehensive. Or like ruby-prof's call graph generation.

That would be useful for communication and understanding, though code -> uml is opposite to the more usual uml -> code direction.

I prefer to use metaprogramming in ruby rather than UML to express high level concepts in code, but as you say some kinds of communication need boxes and arrows....

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

6

Chris Carter wrote:

Our team does believe in Agile and XP
design concepts, so we do a lot of testing, and speccing, which we feel
better documents our code than UML.

And here I thought programming was an engineering discipline, and not a
religious practice. (If you confuse those two, Picocontainer happens.
/me ducks rotten vegetables.)

Also, make sure you don't forget the audience of your code and
documentation. You shouldn't document the code how you feel it's better,
but how whoever will have to read the documentation (to maintain the
code after your team moved on to greener pastures) can understand it
better Believe it or not, these things just might be different - from
the code author's point of view it can be hard to ascertain if
documentation is sufficient since you know what the code is doing /
supposed to do already. (<helen-lovejoy>Won't somebody PLEASE think of
the end users?</helen-lovejoy>)

David Vallner

7

"Joel VanderWerf" <vjoel@path.berkeley.edu> wrote in message

It would be interesting if it were possible to generate UML from ruby
source

Some of this would be simplified if the various flavors of #attr_accessor,
#trait etc. actually kept around a simple representation of the declarations
themselves, rather than just generate corresponding method code.

and/or execution traces.

Wouldn't this be hard without a hook into object creation e.g. via some
dependency injection mechanism?

I prefer to use metaprogramming in ruby rather than UML to express high
level concepts in code,

+1 . Metaprogramming in ruby beats any UML diagramming because you are
starting off with executable code, and can so easily craft a DSL suited to
just your need (rather than have to work with the universal solution claimed
by UML).

8

I always found the following quite an interesting read:

http://starshine.org/xteddy/thomas/~n6tadam/CodeAsDesign.pdf

-- Thomas Adam

···

On Mon, Oct 23, 2006 at 07:14:09AM +0900, David Vallner wrote:

Chris Carter wrote:
> Our team does believe in Agile and XP
> design concepts, so we do a lot of testing, and speccing, which we feel
> better documents our code than UML.

And here I thought programming was an engineering discipline, and not a
religious practice. (If you confuse those two, Picocontainer happens.
/me ducks rotten vegetables.)

--
"Wanting to feel; to know what is real. Living is a lie." -- Purpoise
Song, by The Monkees.

9

Hi all,

Thanks all for replies, it seems that UML does holds a place in agile
develpopment, its not as I thought.

From some of the replies it seems that UML->Code and Code->UML thing for
ruby is a plus for an agile team(if there is a toll like that).

One thing that struck my mind was people say they use metaprogramming
inplace of UML. I'll really appreciate if anyone can give an example how
that can be used. Is it as terse as UML for a team??

regards
gaurav v bagga

10

Hmm, I'm having a deja-vu.

I organized a panel discussion at OOPSLA '93 on "The Role of Methods
and CASE in OO Software Development"
http://www.math.utah.edu/ftp/pub/tex/bib/idx/sigplan1990/27/10/145-145.html

Grady Booch was on the panel, this was IIRC before the three amigos
and the convergence on UML.

Dave Thomas* took the position that the best possible CASE tool was a
code browser.

* A different one, the guy who started Object Technology
International, now enjoying life in the Caribean after making his
fortune selling Smalltalk and OTI to IBM.

···

On 10/22/06, Thomas Adam <thomas.adam22@gmail.com> wrote:

On Mon, Oct 23, 2006 at 07:14:09AM +0900, David Vallner wrote:
> Chris Carter wrote:
> > Our team does believe in Agile and XP
> > design concepts, so we do a lot of testing, and speccing, which we feel
> > better documents our code than UML.
>
> And here I thought programming was an engineering discipline, and not a
> religious practice. (If you confuse those two, Picocontainer happens.
> /me ducks rotten vegetables.)

I always found the following quite an interesting read:

http://starshine.org/xteddy/thomas/~n6tadam/CodeAsDesign.pdf

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

11

gaurav bagga wrote:

Hi all,

Thanks all for replies, it seems that UML does holds a place in agile
develpopment, its not as I thought.

From some of the replies it seems that UML->Code and Code->UML thing for

ruby is a plus for an agile team(if there is a toll like that).

One thing that struck my mind was people say they use metaprogramming
inplace of UML. I'll really appreciate if anyone can give an example how
that can be used. Is it as terse as UML for a team??

This is in C++ (from the book "C++ Template Metaprogramming" - Addison Wesley), but I think this is a good example of what you are asking for:

   // Current Event Next Action
    // State State
    // +---------+------------+---------+-----------------------+
    row < Stopped , play , Playing , &fsm::start_playback >,
    row < Stopped , open_close , Open , &fsm::open_drawer >,
    // +---------+------------+---------+-----------------------+
    row < Paused , play , Playing , &fsm::resume_playback >,
    row < Paused , stop , Stopped , &fsm::stop_playback >,
    row < Paused , open_close , Open , &fsm::stop_and_open >,
    // +---------+------------+---------+-----------------------+

It's a state definition with transitions presented as a table for a media-player.
E.g. if you send 'play' when its 'Paused', the state changes to 'Playing' and it calls the function 'resume_playback'.
It looks like putting the specification or UML into the code.

If anyone has an idea how to do this and similar tricks (from the book) in Ruby, it would be really cool ... In any case, I would expect the implementation to be trivial in Ruby compared to C++.

Regards,
Zatoichi

···

----------------------------------------------------------------------
Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e

12

I was going to say, didn't UML have roots in Smalltalk?

UML is kind of a priestly language, in that it doesn't really seem as
if it gets used in the real world a great deal, but in its defense,
learning UML is pretty good discipline for object-oriented programming
in any language. It's kind of anomalous, because you can't actually
code in it, yet I think learning UML probably made me a better
programmer.

···

--
Giles Bowkett
http://www.gilesgoatboy.org

13

I was going to say, didn't UML have roots in Smalltalk?

I don't know about that.

It really came about when Rational ended up hiring James Rumbaugh and
then Ivar Jacobsen (or perhaps the other way around), which put them
and Grady Booch together. Thus the "Three Amigos" were born and the
three methodologies: OMT (Rumbaugh), OOSE (Jacobsen), and Booch's
methodology were merged spinning out UML as a byproduct.

Grady was a bit of a closet Smalltalker, I believe that the prototype
of Rational ROSE was written in Smalltalk, but it was the C++ types
who seemed to be a more receptive audience to all of the hawkers of
'methodologies' back then.

UML is kind of a priestly language, in that it doesn't really seem as
if it gets used in the real world a great deal, but in its defense,
learning UML is pretty good discipline for object-oriented programming
in any language. It's kind of anomalous, because you can't actually
code in it, yet I think learning UML probably made me a better
programmer.

Ya think!?!

···

On 10/24/06, Giles Bowkett <gilesb@gmail.com> wrote:

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

14

Giles Bowkett wrote:

UML is kind of a priestly language, in that it doesn't really seem as
if it gets used in the real world a great deal, but in its defense,
learning UML is pretty good discipline for object-oriented programming
in any language.

UML does feel overhyped when one is learning about it, and the various
round-trip end-to-end insert-more-buzzwords-here engineering tools are
for projects of a scope most people won't ever see. But it's the whole
missing the forest because there's trees in the way thing. (Or the other
way around :wink:

It's kind of anomalous, because you can't actually
code in it, yet I think learning UML probably made me a better
programmer.

I wouldn't say it's any anomalous at all. UML only lets you manipulate
the "pure" concepts of a given problem. Conceptual analysis of a problem
is a language-independent activity requiring skill. There are arguably
other ways of doing a conceptual analysis or specification of a problem,
not involving UML, and / or involving executable code (e.g. TDD), but
the UML method enforces a clean layering of the model from its
implementation. Having a method that only lets you manipulate abstract
concepts, and lets you manipulate them very efficiently (the main
diagrams of UML2 are really dead simple) can help your brain fold itself
into the shapes that are needed to understand those abstract concepts
properly.

David Vallner

15

That's probably because UML is most often used for class models (more
than anything else, although business types love it for that other
nonsense diagram). Class model diagrams are a poor cousin to ER
diagrams used extensively in data modelling, and learning to do proper
data modelling helps you become a much better software developer (IMO,
you can't do good OO modelling until you know good data modelling in
general).

It also helps prevent you from unleashing stupid data designs on the
world. Too many programmers don't know squat about data modelling.

-austin

···

On 10/24/06, Giles Bowkett <gilesb@gmail.com> wrote:

I was going to say, didn't UML have roots in Smalltalk?

UML is kind of a priestly language, in that it doesn't really seem as
if it gets used in the real world a great deal, but in its defense,
learning UML is pretty good discipline for object-oriented programming
in any language. It's kind of anomalous, because you can't actually
code in it, yet I think learning UML probably made me a better
programmer.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

16

> UML is kind of a priestly language, in that it doesn't really seem as
> if it gets used in the real world a great deal, but in its defense,
> learning UML is pretty good discipline for object-oriented programming
> in any language. It's kind of anomalous, because you can't actually
> code in it, yet I think learning UML probably made me a better
> programmer.

Ya think!?!

I can see my intolerance for script kiddies elsewhere on the Internet
is now revisiting me in the form of karma.

Um, yes, I think so.

···

--
Giles Bowkett
http://www.gilesgoatboy.org

17

> It's kind of anomalous, because you can't actually
> code in it, yet I think learning UML probably made me a better
> programmer.

I wouldn't say it's any anomalous at all. UML only lets you manipulate
the "pure" concepts of a given problem.

well, anomalous in that the other programming languages I've used have
all been languages I could produce programs in.

Conceptual analysis of a problem
is a language-independent activity requiring skill. There are arguably
other ways of doing a conceptual analysis or specification of a problem,
not involving UML, and / or involving executable code (e.g. TDD), but
the UML method enforces a clean layering of the model from its
implementation. Having a method that only lets you manipulate abstract
concepts, and lets you manipulate them very efficiently (the main
diagrams of UML2 are really dead simple) can help your brain fold itself
into the shapes that are needed to understand those abstract concepts
properly.

I think that's right. I learned UML and really never ran into any
situation where it was of vital necessity, but I think the code I
wrote before and after probably has very real differences. the weird
thing is, tho, that UML is generally associated with "big" projects,
and pretty much everything I've done since learning UML, I think I've
actually gotten much better at eliminating unnecessary steps. it gives
you a design vocabulary, and maybe that makes it easier to spot
unnecessary steps before they happen? I'm not sure. I think it was
worth doing. I can't really say that for me personally the jury's come
in yet on UML, but I'd definitely prefer to work with programmers who
have opinions about UML than programmers who don't.

···

--
Giles Bowkett
http://www.gilesgoatboy.org

18

Sorry, but having lived through some rather dubious IBM "Strategies"
which revolved around "methodologies" and magic bullets for building
"big software," I'm rather dubious about the value of some of these
things, other than to those selling the idea.

I don't suppose anyone knows about or remembers AD/Cycle.

···

On 10/24/06, Giles Bowkett <gilesb@gmail.com> wrote:

> > UML is kind of a priestly language, in that it doesn't really seem as
> > if it gets used in the real world a great deal, but in its defense,
> > learning UML is pretty good discipline for object-oriented programming
> > in any language. It's kind of anomalous, because you can't actually
> > code in it, yet I think learning UML probably made me a better
> > programmer.
>
> Ya think!?!

I can see my intolerance for script kiddies elsewhere on the Internet
is now revisiting me in the form of karma.

Um, yes, I think so.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

19

[about UML]

Sorry, but having lived through some rather dubious IBM "Strategies"
which revolved around "methodologies" and magic bullets for building
"big software," I'm rather dubious about the value of some of these
things, other than to those selling the idea.

UML isn't a methodology. UML is a common agreement on how to draw diagrams.

I personally don't feel it gave me much, as informal diagrams had
worked fine for the communication I need to do (including my own
modelling), but the precisely defined notation frees me from having to
explain what notation I'm using to somebody else.

Eivind.

···

On 10/25/06, Rick DeNatale <rick.denatale@gmail.com> wrote: