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
gaurav bagga wrote:
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 V.
that much details of UML. So I was wondering how to gauge how much
important UML is to Agile world.
Last night I bought the “Getting Real” book from 37 signals and I
finished
reading it. Here is the process that they have used with success:
- Draw html mock-ups using paper and pencil. Easy to change and the
cost of
throwing it away is negligible.
- Create static html mockup for your site. Get feedback and make any
changes.
- Code the most essential feature. Less is more. (They talk about
“Epicenter Design”)
- Release. Say no to all the features requested by customer.
Incorporate
only those that align with the “Vision” for your software and is
requested
by most of the customers.
In general there is no artifacts such as documentation, specification or
diagrams created during the product development. They are a waste of
time
since no one can agree on issues. It is easier to know what we are
building
and refine it when we play with the real thing.
It has helped me to think clearly and I have gained so much from this
book.
I now have a blueprint for building a successful online business. I
highly
recommend this book.
Hi!
UML does have impotance in Agile but with the approach is to avoid
paralysis of analysis. The focus is on working code and not the complex
design.
For detail u cn refer to the UML Distilled written by Martin F. who
also is a colossal figure in the world of Agile development. In this
book he
explains how he uses these diagrams himself.
Regards,
Swanand.
David V. 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…
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
“Joel VanderWerf” [email protected] 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).
Hi all,
Thanks all for replies, as mentioned above I’ll go through the UML book
but
as Bala mentioned and I have gone through free chapters of that book by
37
signals.
It might be that artifacts and documentation are secondry things(what is
given in the book) but if accompanied by a tool that helps you generate
it
wont it be a plus point(If used). Other thing being even as you code you
tend to write small notes thats a kind of documentation so why averse
these
things if we can automate a developers process a bit I dont feel it will
be
a waste of time.
What it seems from the above mentioned point (and as I havent gone
through
the book only free chapters) the focus is on getting the job done so why
not
see it from a dfferent angle reverse engineer the things
Code->UML/Documentation(automated process).
I feel documentation(in some form little/more) does helps some point of
a
time,they are 37 signals not all are(not to demean the things but its
matter
of taste and group dynamics not everyone/group is same)
warm regards
gaurav v bagga
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
gaurav bagga wrote:
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
Chris C. 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. (Won’t somebody PLEASE think of
the end users?)
David V.
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.
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
On Mon, Oct 23, 2006 at 07:14:09AM +0900, David V. wrote:
Chris C. 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
– Thomas A.
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.
On 10/22/06, Thomas A. [email protected] wrote:
I always found the following quite an interesting read:
http://starshine.org/xteddy/thomas/~n6tadam/CodeAsDesign.pdf
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 T.* 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.
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
On 10/24/06, Giles B. [email protected] wrote:
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!?!
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
Giles B. 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 
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 V.
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.
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.
On 10/24/06, Giles B. [email protected] 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.
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