Continued from this thread Dave. Matts Smith ------------------------- The reason why this forum is not popular is because UML use is not as widely spread as java for example. Of all the programmers I know (and I know a lot of them) I'm the only one using UML at work (and that's just a little UML). any comments?
raj sekhar ------------------------- .....and that is true. Not many workshops really are taking steps to have a complete design document using uml in place due to various constraints.I want to use UML as much as possible but it just seems not possible with tighter deadlines and user requirements....any buyers? Raj
shanneke mertens
Greenhorn
Joined: Nov 19, 2001
Posts: 2
posted
0
I've been working on a on-and-off basis with UML the past 3 years... (in "how-to-do-it projects" or as a an analyst) The last half year more and more of our customers ask for UML as opposed to only one last year. I guess people are slowly catching the train. I agree on the design probs, same thing here! But as I am an analyst with only limited Java skills I can nt help much to this! shanneke
Wilfried LAURENT
Ranch Hand
Joined: Jul 13, 2001
Posts: 269
posted
0
I want to use UML as much as possible but it just seems not possible with tighter deadlines and user requirements....any buyers?
That is where XP may be interesting. I have just begun being interested in XP and it has an nice approach to UML. One of the idea is that it is difficult to keep diagram in sync with the code. While coding, you will inevitably be confronted to design decision which does not fit anymore. Changing the design implies changing the UML diagrams, which takes a lot of time. Here is an extract of the "XP and UML" paragraph in a Martin Fowler article.
The last point is worth expanding. When you do some up-front design, you'll inevitably find that some of its aspects are wrong�and you only discover this when coding. That isn't a problem if you change the design at that point. The trouble comes when people think the design is done, and then don't take the knowledge they gained through the coding and run it back into the design. Changing the design doesn't necessarily mean changing the diagrams. It's perfectly reasonable to draw diagrams that help you understand the design and then throw the diagrams away. Drawing them helped, and that is enough to make them worthwhile. They don't have to become permanent artifacts. In fact, the best UML diagrams are not artifacts.
So even in the code and refactor philosophy, UML may be useful. W.
Originally posted by Wilfried LAURENT: That is where XP may be interesting. I have just begun being interested in XP and it has an nice approach to UML.
Nice to hear that. Would be even better to hear it in the Process, XP forum In my (sorry) experience, most companies are not sophisticated enough to really make proper use of UML. They often end up doing a half-way job of it, spending a lot of time fumbling with the notation, being more concerned about the "correctness" of the diagrams and symbols rather the correctness of the ideas those diagrams are supposed to convey. That, I feel, is the biggest trap in using UML: forgetting to use it as a medium for communicating the design and instead considering it to be the "design" itself. In XP, the code is the design. This is not a new idea; it's been around since the 70's. I forget who it was exactly who originally said this but the idea is that what is generally considered to be "construction", i.e., writing the source code, is actually a design activity. Construction itself is when you turn your source into something that executes, i.e., when you compile it into an executable program or submit it to an interpreter for translation into machine instructions. If you think about it, this makes a lot of sense. But in organizations that use the "traditional" definitions of design and construction, once you have the diagrams reviewed and signed off, you are done with the "design phase" of the project. And more likely than not, there is very little room in the schedule to go back and make adjustments to the "design". Well, maybe there is but that's what they call the "testing/debugging phase". Junilu
[This message has been edited by JUNILU LACAR (edited November 22, 2001).]
Hi, The root of the problem comes from the waterfall process. Managers still think waterfall works (even if they don't know what waterfall means). Talk to your project manager ask him what are the phases to software development. No one will talk about iterations.
0
