Is UML Really Necessary? 27
rotifer asks: "A while ago I saw Kent Beck talk at the Java user's group meeting here in Seattle. Someone asked him about UML. He made a derisive noise and sneered that he had come up with a better version called GML, Galactic Modeling Language. He said (and I am paraphrasing here) that GML had three components "Boxes, Arrows and Arrows Pointing to Boxes". I thought this was right on. That seemed to be all the object modeling a person would need, especially when compared to the 808 pages of obtuse documentation that make up UML. But am I missing something here. Do people find UML useful. Or is it just overblown hype? Do you need this fully featured language to design an O-O system? Or are you better off with just boxes and arrows? Also, if you were to teach programming to beginning Java and C++ developers, is it a good idea to start with a course in UML so that new programmers can become familiar with O-O methodology before they start to cut code?"
Excuse for sloppy thinking (Score:1)
Often tools like Rose also make you concentrate on the wrong things, trying to make a diagram fit onto a single sheet of paper for example. I prefer a pencil and paper (and word processor when I'm done). I also have reservations about how maintainable the design is and how scalable the software (not methodology) is.
However, a team "thinking" and documenting things in the same way *is* a huge benefit and shouldn't be underestimated. UML is becoming more and more popular (by management mainly) and you'll probably have to learn and use it regardless of whether you like it. May as well get used to it...
Re:You don't NEED anything.. (Score:1)
If I could draw graphics here, I'd remodel your sentence for you.
Re:Not just class diagrams (Score:1)
Re:Too complex? Yes. Useful? Yes. (Score:1)
UML vs Boxes, arrows, and arrows-pointing-to-boxes (Score:1)
Re:UML usage (Score:1)
State diagrams are occasionally useful - Like most parts of UML you shouldn't feel the need to use use it for all classes. In my last project we had of the order of a hundred business classes, and only six state diagrams. Each state diagram was for a different subclass of our transaction object. Nothing else had an interesting enough lifecycle to warrant one.
Re:You don't NEED anything.. (Score:1)
Somebody gave you hardware prebuild hardware, you lucky bastard we had to make do matches and bits of string and the odd tin can
And tell that to the kids today and they won't believe you
Re:Class Diagrams good, Use Cases Not so good (Score:1)
Knowing all the actions your system components are expected to support can be useful to get a grasp of your project's scale. I did this before i knew it was called "use cases", so i thought it was cool that there was a name for it (not that i like the name, or anything).
Re:You don't NEED anything.. (Score:1)
You are right, however, about only needing to toggle bits on the registers. Back in my day, that's what we used to do. We didn't have these fancy-schmancy mark-up languages and modeling languages. Bagh.
You don't even need these bloated tools if you just steer clear of OOP programming! Does assembler have an object or a class?
UML usage (Score:1)
Class Diagrams good, Use Cases Not so good (Score:1)
Too complex? Yes. Useful? Yes. (Score:2)
Yes, IF you make the effort. (Score:2)
I'm using Shlaer-Mellor here at work. UML is our reprsentation, and it works great. What makes it work though is we keep the models up to data. In our case this means our tool turns the UML into our header files. So if you want to modify a header file you have to go into the tool and change the model.
I've never worked with anything else, but others around here have. (booch mostly) They all agree that it didn't work, and the reason is the models got out of date.
So, UML can work great, but you must make sure that that your models stay up to date. Looking at a graphial chart of a "domain" makes it easy to learn the structure of the program when you are maintaining someone else's program. Make the effort (and it is work that you won't like) to keep your models up and it is great, otherwise it is a waste of time.
PS, shlaer-Mellor (and our tool) also allows us to go a step further and generate all the code from a 4gl. This works fine for non-time critical stuff, but for the stuff where speed matters don't use it)
UML (Score:2)
----------
Re:You don't NEED anything.. (Score:2)
I use UML, but keep it simple. (Score:2)
I'd recommend the book UML Distilled by Martin Fowler and Kendall Scott. It is a very small book that documents only the most necessary, commonly used parts of UML, rather than the whole thing. I tend to use "fuzzy" UML. I don't worry about the anal-retentive nuances of UML, I just use it to draw some quick & dirty diagrams to figure out what I'm doing.
Not just class diagrams (Score:2)
Even with class diagrams, if you care about multiplicity and aggregation vs. composition, then you'll appreciate the UML.
On the other hand, if you are a Cowboy Coder, or if you're as allergic [martinfowler.com] to paper and ink as Kent is, then you'll do fine with napkins and felt-tip pens.
Far and away the greatest thing about the UML is that it is a widely-used and understood diagramming notation. Your alternate is some weird propriety notation that probably makes no conceptual sense *cough* bliner [varatek.com] *cough* used where it isn't intended, or some strange diagram thrown together in Visio by the graphic-design-impaired system architect with the symbols he thought looked pretty.
Re:You don't NEED anything.. (Score:2)
- If you're building something mission-critical that is well-understood, getting it right the first time is crucial and benefits greatly from detailed design. Building a banking system? UML is a good idea. Bugs lose billions of dollars.
- If you're doing something researchy or with a poorly defined specification, a few rounds of rapid prototyping can be immensely useful. As a research programmer in user interfaces, I found rapid prototyping to be extremely useful. You don't always know what will work well before hand because much of it is so "squishy" and not amenable to formal analysis.
Anyone who always uses only one or the other is either handling a narrow category of problems or is making more work for themselves than they need to. Me, I'm lazy. Amen, Brother! So Sayeth Fred Brooks. No particular design tool or methodology or anything is the uniform ideal thing. Sure, it's all Turing-complete, but then a hammer will eventually cut a 2x4 board in half by breaking enough wood. The saw is still a better tool. Model-View-Controller works for some applications, but for others it rotsBefore anyone jumps on me for dissing MVC, try doing a model-view-controller design for intelligent handwriting recognition like on the Newton or Calligrapher. You've got semantic word recognition (my Newt spells better than I do, and I'm a good speller that routinely ignores spell checkers because my writing generally includes more jargon that the checker doesn't know than mistakes), concurrent ink and recognition that removes ink as the words are recognized and replaces it with formatted text. Shoehorn it into MVC and you'll either get one of the MVC components doing all the work or the bandwidth (API size) between the three MVC components is massive, indicating poor encapsulation and suggesting a different approach to the design should be taken (the "spaghetti of callbacks" problem, rampant in most modern UI toolkits).
By coinky-dink, this is exactly what the CS textbook did that I wrote lo these many years ago. Actually, we used OMT, because it was 1994, and Booch and Rumbaugh were still sparring with each other. I imagine that the students in that class were well-prepared when UML came along - they'd been using a similar notation since they learned to program (this was a first-semester textbook).Re:You don't NEED anything.. (Score:2)
<voice="grumpy old man">Heh, hex editor! Whatta ya need that for? All you really need is your index finger to toggle the bits into the registers. Next thing you know you be wanting an assembler and a compiler and an IDE. Flim-flam. All that is for the weak.</voice>
_____________
Re:UML can be insanely useful (Score:2)
--
Problems (Score:2)
Re:UML is useful. (Score:2)
Don't forget the generalized nature of UML. I work in Systems Engineering where we see plenty of box-and-arrow drawings. Most of them don't make any sense when you are unsure if they refer to Hardware or software. Do they refer to materials flow, data flow, network traffic, or parameter flow?
UML provides a standard which is very useful in these types of problems. I've always been a fan of very specific details at the cost of readability. In a complicated system, e.g. a f-18 jet's cockpit, you need to be specific. Lives are at stake.
Kent Beck Is eXtreme (Score:2)
What UML brings to the table is a standard way of documenting complex models and systems. If you sit in a room with 10 people and spend a day drawing a system with boxes and arrows, everyone in that room will understand the diagram. If you send that diagram to another company or organization intending to collaborate on implementation, odds are they won't find it so useful.
On the other hand, if those same 10 people are solely responsible for implementation and they spend 3 days arguing about correct UML usage, they've just wasted a lot of time.
Think about the right tool for the job and be wary of anyone who tells you their solution will always be the best solution.
UML can be insanely useful (Score:3)
Secondly, if you're only doing high level modelng then GML is fine. Napkins are probably good documents for this too, or perhaps the back of an envelope. One of the fundamental assumptions to UML is that there is a group or a team doing the work and so the diagrams are designed to transmit a very large amount of information. A full and complete UML diagram specifies how the code is to be implemented, it's a complete design, member variables and functions are all listed and all you have to do is fill in the blanks. This is a big deal, you can give such a design to any coder and he should be able to implement it.
This all hinges on the value of design which is a dying art in many ways. Sure you want to get good code fast and you will probably end up rewriting things but there are still times and places for good solid design. I've seen a couple projects when one or two people built a full UML design doc and spent a couple months doing it and then a team of 10 people implemented the code in days. I think we all see ourselves as software designers as much as developers and that's not the most attractive way to work but there is still a time and a place for it.
You don't NEED anything.. (Score:3)
Having said that, UML is one of the tools in the good O-O programmer's toolbox. I don't use it right now because I haven't had a chance to learn it fully. But based on my perusal of the spec, it's quite useful as a structured method of laying out how a system works. That's also because I prefer to not use a tool until I know what I'm doing with it.
It's not a magic bullet that will enable you to solve every problem in a generic fashion that will work all of the time.
At the very least, if one is teaching beginning CS, they should use UML graphs to teach concepts instead of whatever graph notation the professor feels like using. That way, people will be comfortable with UML if they encounter it later on.
Yes! (Score:4)
Now, I've been working with UML for several years now, and I've always found that it is a bit two um, "wordy" ( but with graphics
It really appears that most devlopers tend to obsess about it.
Years ago, A group of developers I worked with came up with what, at the time we called "modified booch notation". Really it's very similar to GML, but without the boxes.(people would draw the clouds/boxes, an the text wouldn't fit, so we eliminated the boxes and just wrote the text.). With all the bright developers I worked with, this turned out to be great. Everyone was understanding the entire model, very quickly. (no UML->brain thunking...
I would not heistate to say that UML makes new developers afraid, and doesn't assist in the absorbtion of information any faster than GML.
UML is useful. (Score:4)
UML is more than boxes and arrows showing inheritance. Derivation, composition and aggregation are all distinct concepts, and having those immediately visible instantly clarifies a design. UML-based sequence diagrams clarify the structure of a project up front, getting the rationale behind a project's structure in your (and others') heads straight off. Normally it takes a lot more hands-on time with code to really grok a project the way UML helps you to do.
Seeing relevant data and methods there on the page also helps in rethinking the flow and arrangement of data. And good data arrangement is the most significant bit of optimization a project can have, and even a simple UML editor implementation like you get with dia can help you make positive sweeping changes before you've written a line of code.
Using UML, we've successfully shortcutted a lot of iterative design, and our prototype code tends to look very similar to our final code.
---
My opinions are mine.