• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

UML: Yuck!

 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just curious--am I the only one in the JavaRanch "I Want to be an Sun Certified Enterprise Architect" universe who thinks that UML is a profoundly silly waste of time? I can't believe I have to study this nonsense.
 
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Cleland Early:
Just curious--am I the only one in the JavaRanch "I Want to be an Sun Certified Enterprise Architect" universe who thinks that UML is a profoundly silly waste of time? I can't believe I have to study this nonsense.


Cleland,
I don't buy into the creation of every type of diagram or even applying it in all situations for all projects, but for large projects being implemented by several developers who are familiar with UML...it can be helpful. To me, it provides some of the same value that design patterns provide:
A common language of design that conveys more in fewer words (..or pictures). The documents can be picked up by anyone (...who understands UML) and can convey significant amounts of information that would otherwise take alot of "code walking" to glean.
If you use "pictures", but employ a non-standard format/nomenclature, then you spend alot of time explaining your semantics to others. UML lets you skip that and get to the design.
I like component diagrams, class diagrams, state transition diagrams and conceptual diagrams. I tend to shy away from sequence diagrams and collaboration diagrams unless I have a trully complex or critical interacation that is not self evident. In that case I'll tend to use a collaboration diagram only in those rare/specific cases and not do them for everything. The only time I would ever do a sequence diagram is if someone forced me to do it (i.e. customer mandated requirement).
 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A picture is worth 1000 words.
Also, if you look into the UML user guide by Grady Booch (or maybe I read it somewhere else), Booch says that 85% of UML modeling can be done using just 15-20% of the UML.
Only thing I don't know about this statement is which 15-20%. My personal opinion is that class diagram and component diagram is very useful. I am not a great fan of sequence diagram though.
Also for being SCEA, you don't have to spend a month studying UML. Maybe a day or two should be just fine. There is a nice UML tutorial on Together site.
Harsh
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you're not using UML, are you really doing object-oriented programming?
 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just curious--am I the only one in the JavaRanch "I Want to be an Sun Certified Enterprise Architect" universe who thinks that UML is a profoundly silly waste of time? I can't believe I have to study this nonsense.
IMHO it is UML which is the key of successful development of large enterprise applications. Specillay if development is done in distributed environment.What else could be used for teams spread across the globe, where language could also be an issue, team communicate with models. I have found balanced use of UML result in increased productivity and reduces communication gaps within team. I would say one should go for it and choose appropriate set of diagrams from the UML based on project complexity and team structure.
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, remember when "Flow Charting" was all the rage? They even taught it in school. Hopefully UML will die the painful death it deserves, like "Flow Charting". I agree with Cleland, what a silly waste of time!
 
Cleland Early
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, yes, I do object-oriented programming. I find that I'm perfectly capable of designing a system without drawing pictures. If only 15-20% of UML is really useful, why have the rest of it?
My development methodology usually doesn't include the massive up-front analysis implied by the UML way. I usually take a prototyping approach, where I develop an initial system with a subset of the desired functionality and gradually add new features. In my experience, changes of direction are quite common. What happens to your carefully prepared diagrams then?
 
Cleland Early
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The key to successful development in any environment is having imaginative people who know their stuff doing the development.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cleland - what would you do if you had to leave the project suddenly and the application was left to be implemented by another developer? Or if you were just doing the design for someone else to implement which is often the case.
How would they know what you were thinking?
 
Cleland Early
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In truth, most of the projects on which I've worked have been solo or involved one or two others, so communicating with other developers hasn't been an issue. I don't find diagrams to be useful, and if I were presented with a bunch of them, my reaction would be "Show me the source code!"
When I design a system, I usually create source files for the system's objects. At first, the classes defined therein might be skeletons to be fleshed out. I think you could easily divine a system's design from such source files. I think JavaDocs are also helpful in figuring out a system's design.
 
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Before I dislike documentation, I just thought it was a kind of wasting, esp when the time frame is limited. Whereas good documentation DOES help replication of idea and skills. Someone may argue only few ppl get involved in the projects or even only the developer itself involved may it not be so neccessary. Whereas to me, I think it helpful in communication not only to the rest of the developers but also your boss and the most important, YOUR CLIENT. And it provides a standardised means of language for discussion.
 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I think Architects job is not only in designing a efficient and reliable software solution, but also in communicating the same to others, for that UML is the best solution.
Hari
 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree that for smaller projects things can easily be worked with scratches of paper and some thinking. But if you are working on a medium sized project developing frameworks then UML really helps in clarifying all the chaotic expressions in the mind and can be thrown away to a corner. However in enterprise level integration it is extremely useful in churning out interfaces for service level agreements.
 
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I found that UML is also useful to communicate with no technical clients to get their input for functionality or agreement with them.
 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To understand an existing a project, it is much easier to review the UML diagrams than to go through all the source-code.
But, I think, only 2 out of 8 diagrams are really useful. They are Class and Sequence diagrams.
Srikanth
 
Ranch Hand
Posts: 263
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
<<
> Yeah, remember when "Flow Charting" was all the >rage? They even taught it in school. Hopefully UML >will die the painful death it deserves, like "Flow >Charting". I agree with Cleland, what a silly waste >of time!
<<
hehehe.. i seem to like this statement .
Isn't RUP (Prototyping based !) and UML at loggerheads with one another ? Wondering.
 
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i don't agree with this. i mean, uml is a very high form of abtraction. getting from "p-code" to assembler, then to pascal, c, java, this is the journey, and it's going towards a higher form of abstraction, because it costs less and gives us less headache.
we won't be executing uml in most of the real projects any time soon, but for a reverse-engineered code - can give u a great overview of the code. and it stays synch with it!
where i work, we have source-codes that are partly 35 years-old. there was constantly ateam of over 5 people working on it, fitting it, adjusting it for that time. there are 10.000 programms, over 10.000.000 lines of code! you can't take a look on that, to know what it does!
i wish i had that uml diagrams! yeah, that'be great!
Rudi
SCJP
SCEA I
reply
    Bookmark Topic Watch Topic
  • New Topic