- Posted by: Pratik Patel
- Posted on: July 26 2002 10:23 EDT
I am interested in finding out how much UML is actually used in real projects. Well, more specifically what percentage of projects broken down into two rough categories w.r.t J2EE:
* What percentage of Webapp projects (Servlets,JSP,Struts, etc only) do you think use UML modeling at the various stages of development?
* Similarly, what percentage of Webapp + EJB or just EJB projects use UML modeling?
Someone asked me this question recently, and I had to give a "I'm not sure" response. Also, your thoughts as to why it is NOT used would be useful to know.
- Does anyone actually use UML? by Mohan Navaratna on July 26 2002 16:40 EDT
- Does anyone actually use UML? by Mark McCarthy on July 29 2002 11:41 EDT
- Does anyone actually use UML? by Sean Broadley on August 01 2002 17:41 EDT
- now-really by Jimmy Bo on June 30 2011 10:16 EDT
we do use UML for use cases,analysis and designing and implementation in our project .
But you are right . I have seen very few of my friends using it . I blame the companies for this .
They think its a waste of time to do this kind of analysis .
But its going to be a very use ful too for big projects as well as maintanence type of projects.
UML will be a boon for projects developing products.
Thats my two cents.
My company is using UML extensively in the design phase. Personally, I believe that UML harnesses a power not to be left unused. I agree that everything defined using UML could be described as a Word document, but really, who writes as clear specifications as UML is in pure writing?
My former employer did not use UML formally - some of us explained ideas using sketchy UML but no formal documentation was written in UML.
I believe the reasons for most companies not using UML are:
1) adequate UML tools cost $$
2) software engineer drawing boxes isn't being "productive"
3) the project is a web site without future maintenance
4) "Bob, how should I draw a jsp page? Actually, I don't think we need UML for this one, do we?"
My company's use of UML is probably dependent on the project. I worked on a java/Oracle project that used UML. I think the big issue is always time. If the project is rushed to deliver the time needed to incorporate UML standards may be too much.
I think the methods used also depend on the project manager's tastes. I really liked using UML and was pleased with documentation it allowed us to have and share with the client.
Yes, of course we do. I'd consider any OO project that didn't to be a bit, well, amateurish.
How do you expect to understand what you're doing without a Domain Model? How do you explain your transactions without a sequence diagram? If you can't explain it, others can't review your design, and if no-one is reviewing your design then why are you bothering...
But there are two uses of UML:
1) Part of the design process. You draw pictures, write comments, wave your hands in front of it, and explain it to people. Usually on a whiteboard first. Then probably Rose (or an equivalent tool) as part of your design doc. I think this is the 'true' use of UML - you don't model every damn method of every damn class, but you cover all the crucial bits. And your diagrams need comments. Lots of them.
2) Documentation, produced as part of a development project's deliverables. This should be formal, and complete.
I think people often confuse these two things. One is part of a process. Another is a finished product.
I have only worked on 1 project in the last 15 years where UML was used. The developer was generating a ORM from Rational Rose MDL files. I have to say that it interfered with the development significantly.
UML is not the way to develop software. Software is an interative process of developing prototypes, the modules or components being prototypes. It is not a "top-down" process with drawings of boxes and lines that "architects" "proof-read" before "handing them off" to the junior developers.
UML, and the philosophy behind it, is a huge cash drain. UML software continues to be sold quite profitably because managers and the like continue to think that software fails because of bad design (correct), and that the way to make it succeed is to increase the design burden with UML diagrams (false).