Has anyone used UML?

[Harry George]

I've done "software engineering" data and process modeling in big
death march projects and in small XP efforts.  In every case, the
problem is to use models/diagrams where/when they are needed, not just
"because they told us to".  And the only way they seem to be
maintained is if there is no printed documentation -- everything is
live on the web.  Edit and publish in a 3 second cycle time.  

Under these circumstances, UML models (specifically Dia) make sense
for conceptual modeling, logical data modeling, a dash of DFD's, and
the occassional state diagram.  The idea is to bring the community of
players into a high0-level mindmeld as ASAP, not to lock down every
nuance of the implementation.  Then do design and code reviews on the
implementation, which conveniently is in an easy-to-read langauge,
like...python



grante at visi.com (Grant Edwards) writes:

> In article <3B1BC755.65510E63 at bt.com>, Alan Gauld wrote:
> >
> >> I took a 3 day class on UML once.  My impression: yet another
> >> "silver bullet" that doesn't work in real life.  
> >
> >Like any design notation UML is there to communicate. If 
> >the peer group is small enough the advantages are marginal.
> 
> Agreed. All of the projects I've worked on have been small (1-2
> people typically, 4-5 max).  Resources are always scarce and
> when schedule and budget gets tight, maintining the system and
> design description always seems to be the first thing to fall
> off the bottom of the priority list.  
> 
>   "Just get the fix released to production, and we'll worry
>    about updating the documents later..."
> 
> >If you are working in a distributed group of 20 or more 
> >programmers something likev UML is near essential. Most 
> >of my projects involve several hundreds of programmers
> >(250 on the current one) and there we simply couldn't 
> >operate without UML.
> 
> One of the problems I've run into consistently over the past 10
> years is when management insists on using "big project"
> methodologies on tiny projects.  Their reasoning seems to go
> something along the lines of: If one person can do a project
> like this in nine months using the "seat of the pants" method,
> then if we make him use Flowcharts/SASD/UML/whatever, then it
> should only take half as long!
> 
> >> thought it was marginally useful, but like any other form of
> >> documentation, if it's not maintained (and it never is, AFAICT)
> >> it becomes worse than useless.
> >
> >It depends on the level that you work at. Architectures don't 
> >vary that much and are useful for maintainers. But code varies 
> >a lot so if you try to use UML for documenting code without 
> >tool support for reverse engineering changes then I agree it 
> >quickly becomes out of date.
> >
> >But How else do we communicate design to a new start - it takes 
> >a long time to read a million lines of code.... UML and similar 
> >tools cut that time down by an order of magnitude.
> 
> I agree that you certainly need something for documenting large
> systems.  The fashion in what that "something" is has varied
> over the years, and UML seemed as good as anything (certainly
> better than some).
> 
> -- 
> Grant Edwards                   grante             Yow!  -- In 1962, you could
>                                   at               buy a pair of SHARKSKIN
>                                visi.com            SLACKS, with a "Continental
>                                                    Belt," for $10.99!!