Slashdot Mirror
How Do You Use UML?
christophe.vg asks: "We are currently investigating the feasibility of a new (open source) project and part of this study involves a scope definition of how people/developers currently actually use UML. So there it is: How do you use UML? Do you use it to have nice class diagrams to pin up to the wall so you/it just looks great or do you first model out every little detail into class and sequence diagrams before generating or writing even one line of code?
Now for a moment, let's dream the UML dream. Do you think that in the future one could maybe even envisage software development where UML could simply replace all existing coding languages? One could argue that coding languages are merely formatting tools to implement the actual logic, which can be portrayed 'in a Unified way' using UML schemas. What are your ideas regarding the real merits of UML, currently and in the not so distant future?"
UML is a language, not so different from C or Java. It's good at representing some things, like structure relationships and certian kinds of high-level sequencing. It's not so good at others, like complicated data stuctures or calculations. It would be silly to write a memory manager in UML.
;-)
I use a bastardized form of UML on the whiteboard when I need it. It's not in any way official, just enough to get the point across. I occasionally will put that on the computer using visio, but again without much regard for form. I'm not one to think in UML itself, so all of the modeling tools that are designed around it tend to slow me down more than anything.
I'm perfectly happy with my way of doing it, but maybe I just haven't seen the light. Could be that a few weeks of Rational "training" would reverese my opinions entirely.
See you, space cowboy...
The way I use UML is as way to select projects I want to participate in. If it uses UML, I'm out. The correlation of using UML with rigid authoritarian organization and fighting with "productivity enhancers" rather than developing software is too high.
It's a pity, because visualizing the structure of a program can be a Good Thing. Still, the idea behind UML isn't exactly new, and does not seem to be very successful historically.
Please correct me if I got my facts wrong.
In late 1998, I was working for a small company that decided to explore this new-fangled UML. A group of about 10 of us took a week-long course on it, and learned the basics of it. We decided, as a practice project, to re-implement one of our small subprojects with UML. We spent a few hours a week working on this.
When I left the company in April of 1999, we had made no signfigicant progress on the project.
I rarely use UML. Sometimes in class they force us to use it for things, even grade us on it. But its just a waste of time really. The problem is that some people use UML to layout the design for their application in full, or part, and then build the software following that design. But inevitably the design goes through a thousand changes. Most often a simple flow chart is quicker to make and more useful for this purpose.
What UML IS good for is communication. If you have a software design and you want to communicate that design to someone else, then UML is a handy tool. It's also useful for division of labor. You can make UML for the project and divide up the pieces of the diagram each programmer has to do. But in this situation you're really just commicating the design to each other, which is all UML is really good for.
The idea that one day we can just make UML and not have to code in C or something is ludicrous. If we move away from "real" coding it will definitely be to a much more abstract tool than UML which will write code for us. You can see it happening already like all the drek that Visual Studio comes with.
The GeekNights podcast is going strong. Listen!
At the company I worked for until very recently we mostly used 'UML as a sketch' on the whiteboard as a way of turning our ideas into something concrete we could implement. Simply having a standardized set of whiteboard notations hugely improved the effectiveness of communication between team members.
We mostly used class and sequence diagrams, the latter being very effective for dealing with multithreaded code.
To a much lesser extent we used computer generated UML when reverse-engineering with tools like Together to understand older, pre-existing code.
We didn't get into formal use of UML for requirements and design in our small team.
UML is best used for informally descussing the design of existing/proposed code. Alternatively it could be used to document existing code.
When teaching coding classes, I usually use UML to demo basic object interactions and class structure on the blackboard. If I instead write a bunch of code I wind up receiving glazed looks from my students. It takes several days to teach the syntax of OO programming to students but I can have them drawing /comprehending rectangles in a matter of minutes.
For my own programming projects, I usually use UML to code stuff up with pencil and paper on the bus and I then "translate" it to actual code once I get home.
It sounds like what you are really interested in is not UML but VPLs, Visual Programming Language (not to be confused with things like Visual Basic which is a fairly normal programming paradigm with some RAD gui development tools built in).
Programming with boxes and wires is the way you code in such languages. Anyway google for visual programming language and you will find lots of stuff. The VPLs also allow you to draw your state machine for a component visually. This permits writing your entire application visually, as opposed to just connecting up components.
I think one of these days we'll create all applications in this way. What could be better for an architect than having your entire application as a very clear, always up-to-date diagram, which can be zoomed in or out to get whatever level of implementation detail you like?
I write a lot of device-control kinds of applications. The high-speed stuff (> 1kHz) benefits tremendously from hierarchical state machines. I began using the mechanism Miro Samek proposed in "Practical Statecharts in C/C++". See http://www.quantum-leaps.com/.
This is a very nice framework for taking your statecharts directly into code. They are also pretty efficient.
However, in a couple of cases, I had to abandon his framework, because the DSP implementation ended up being too big to fit into my DSP's cache. So, I broke down and rewrote it all using a nested-switch. It's uglier and more bug-prone, but it fits in cache and helps me keep my high speed loop fast enough.
The nice thing about the hierarchical statecharts is that they help simplify the problem in ways I did not think about previously. Behavioral inheritance is a great concept, and having a way to think about it graphically has sped up my designs.
I cannot help but recommend Samek's book and the use of these hierarchical state charts. They are helpful, especially if you're doing control problems.
There's no time to stop for gas, we're already late.
That's a very interesting take on some specific issues one often comes across when trying to use UML.
Personal experience has shown that some of the features of UML are useful. We often use class diagrams to help new developers on the project get quickly up to speed. The class relationship information, which is what they need, is more densely represented in UML than as code. That said, we rarely use most of the other artefacts. Pseudocode and flowcharts often seem to work much better.
When it comes down to it, UML is sometimes a useful communication tool, but that's about the extent of it. When you have a bunch of developers who communicate better in some other way, you use that instead.
My major problem with UML actually is that the tools to design it are a pain to use. I never saw one that would feel as easy and natural to use as pen and paper is to draw structures. I do plan my structures, patterns, class names, responsibilities before starting to code, but I just hate using UML tools.
Reverse engineering tools are nice because they are quick to use but the results are either too details or not precise enough. Relations are usually association, extend or implement. UML has a whole lot more details and those tools seem to ignore them unless you set them manually, which is what you wanted to avoid in the first place.
I remember working on a project where we made the entire structure before writing a single line of code in UML. We made it all as a team and all agreed on it. The first guy to actually started codiing it totally ignored what we made. Great! We simply wasted time!
As a side note: I'd be very glad to see a UML editor that is actually aware that paper exists. I just love the fact that Rational Rose has no print preview and won't tell you where the page ends. Want to print? Guess and adapt until it looks fine. As a plus, it has no image export. This is really what you get for a few thousand dollars application.
Qui ne va pas à la chasse n'a pas de gibier
PHP Queb
The other parts of UML I do not find so useful. I mean, I could just use regular flowcharts, state tables, or class declarations instead of the UMLized equivalent.
UML is just a way to describe your software requirements and design. Heck, you can even use regular English prose if you like, just like the good old days.
The art is to know how much modeling is enough. This depends on the development tools you're using (languages, IDE's), the problem you're trying to solve, and the skill level of the developers and "buyers" of the project. I find it most useful at a higher level of abstraction: activity diagrams are really good afor understanding business processes; a high-level object model is usually a good thing to have early in the project definition phase; and I always want a convincing story on object life cycles before we start: this probably involves realization and sequence diagrams.
I seldom use more than 20% of the semantic richness of UML-- I use it more to "rough out" a description of objects and their behavior. Part of the reason for that is that there is no value in using UML to replicate capabilities that are already built into the development tool suite. And detailed modeling of stuff that doesn't matter is just bullshit. Anyone who documents every page on a website with a sequence diagram that basically tells you nothing should be taken out back and shot. Since I'm usually the tech lead on projects, I'm the one who tells the clients what we use and why. And if they expect some UML feature that we're not using, I tell them why we're saving them money by tailoring it out. If your management aren't capable fo doing that, they aren't fit for their jobs.
My main point is that UML is a common language to make analysis and design more effective. It's only useful when it does that. Knowing when it's helping and when it gets in the way is a judgement call for which somebody had better be prepared to take responsibility. Unthinkingly doing everything everytime to insane levels of detail is nothing but a shameful waste of resources. It should be the yeast, not the flour, in your loaf of bread. It cannot take the place of intelligence.
Get your teeth into a small slice: the cake of liberty
dumb question but because I am not a developer I'll ask anyway. I am seeing the comments on "code commenting". Aren't there any editors that automagically generate at least some sort of generic commentary as you code along? I guess I assumed this was the case already. I know specific things you'd have to type in, I just though a lot of the general stuff just got "done" as you typed in code according to what language you were using, etc.
anyway.. where is the speech to code to useable apps dealie? heh, that's what I am waiting for.
Hmm, maybe coders and coding shops need to hire IT proficient but primarily english majors/experts/writers to follow along in real time as much as possible with the coding being done by the geeky and cranky guru pros and add in human readable commentary, and then write the manual pages as well. Eliminate that painful step (for other people down the line) of having to translate and decipher what the esoteric guys were trying to do with their code.
I'm on a project that is using Executable and Translatable UML (xtUML) for developing embedded firmware. The target is an 8-bit microcontroller.
Our software process involves doing an extensive requirements analysis phase. Next, we break the problem down into domains, which are further anaylyzed. Finally, we begin work on the class models and state models.
The xtUML methodology includes precise semantics, which allow it to be directly translated into C using off-the-shelf compilers. Or, you can be brave and write your own model compiler to directly translate your models into the target assembly.
There is some high-level action specification language code which is written for the state actions and instance based operations, but besides that, no coding is required.
Check out this site for some xtUML information: http://www.projtech.com/
That poor requirements problem is part of what's keeping your job from going to India. Once they've gone through the hassle of writing everything down as use cases ... they might as well fax it offshore.
Think about that next time some guy from marketing drops by to ask for a new feature.
#!/usr/bin/english
Sad to say, the only fellow I know who is actually gung-ho on UML writes scary code that easily breaks.
The following may seem facetious (sp?), but I'm genuinely curious: does anyone have a story involving UML with a happy ending, along the lines of "Wow, if it weren't for UML we'd have been in big trouble?"
Well... if you want to get into pdeantic details... the <abbr> tag is probably to be favored. The W3C spec spells out the difference down in section 9.2.1. Of course, finding out which versions of which browsers support which tags is another problem altogether.
BTW, I find the WDG's guides to be more technically accurate and helpful. Much of that could be due to their documentation being machine generated from the official DTD's and such.
UML should be used to DESIGN your programs. After all it's "Unified *MODELLING* Language", not "Unified nifty diagrams documenting language".
Lack of previous (even on-paper) design is what makes programs buggy. When you code first, doing the UML diagrams is useless. Why? Because when you find out the structure of your code and see possible improvements, you realize that it's too late to make any changes, due to compatibility problems, etc etc etc.
Look at what happened to the Lazarus project. it's been on "pre-beta" for more than 6 years, and they 're still telling me it's too early to make an UML diagram because "the structures change too much". (WTF?!?!? If I want to cooperate in a project, the least i can ask for is the UML diagrams so i can focus on where to help, not navigate among the millions of lines of code!)
Follow my advise. Design first, code afterwards.
When I think of UML diagramming, I think of the old-school Object Oriented Design approaches to client-server development and how it used to be fassionable to pay a close to a dozen high-rate contractors to philsoophize on the merits of alternate approaches to object design. Back in those days, cost was not an issue and every company thought they had the edge since they had all the OO visionaries huddled together in their conference room. Of course, things have changed and companies don't want to just blow money for the sake of blowing money. IT expenditures rarely increase revenue, so the focus should be on how to cut the cost of the plaform and the cost of the applications. Heavy use of UML is often the cause for outsourced efforts being as expensive as local development - boatloads of UML diagrams are normally required to properly instruct offshore teams. The new modern model is to cut out all non-value-add activities, including UML, and go from business user or func-req directly to source code development. Doug Hettinger www.SoftwareObjectz.com
http://www.softwareobjectz.com
The tragedy here is that the big marketing machines have brainwashed the gullible, desperate, and ignorant into believing that UML is a silver bullet. As a result, diagram making robots are often directed to generate their beautiful models for unknown stakeholders and with unknown value to create the illusion of progress (Gravitational Fever: Afflictees measure progress by the weight of their UML diagrams).This is just one scenario of many that gives the UML a black eye.
Let's face it, any tool can be misused and abused. People need to learn to use the UML where it is valuable to do so, at the proper level of detail, and with appropriate completeness. When used under the proper adult supervision, the UML truly can be a valuable communication and visualization tool with which to improve productivity as opposed to killing it.
Is Death by MDA Fever around the bend?
I agree with much of your post, particularly these excerpts [emphasis added]:
To answer the original question, I find aspects of UML useful in two places:
Oddly, though apparently I'm not the only one, I usually prefer to do the prototyping work with the Mk. I Pen & Paper(TM). I find most "UML design software" hideously awkward to use. (If you do want to produce decent diagrams by hand, perhaps to put in a document that's being circulated to colleagues, then Pacestar's UML Diagrammer is the most simple-but-effective software I've found thus far, though of course YMMV.)
For documentation once the project is going, I subscribe to the view that the code should be mostly self-documenting as far as details go, but separate formal documentation should explain the "big picture" ideas. Tools like Doxygen are great for this. They generate class diagrams and such for you automatically, thus keeping everything up-to-date without much further effort on the part of the development team, but can also
- provide a home for your written explanations of major ideas
- reference key classes/functions in the generated areas of the docs, as a starting point for someone new to that area of code to find their way around
- pick up summary comments at the start of functions and the like
thus keeping all your documentation in one place, without requiring error-prone manual duplicate of information you already wrote into the code.IME processes that insist on using UML for anything more than either throwaway prototyping (when generated by humans) or reference material (when generated by software tools) tend to be far too heavyweight to be useful. In particular, I have never yet encountered a so-called "round trip engineering" process that actually did more good than harm. (That doesn't seem to stop many management teams deciding to mandate their use, alas!) Still, you can always waste plenty of afternoons trying to get that sequence diagram in Rational Rose to both look correct and work correctly if writing the equivalent C++ or Java in two minutes is too easy for you, and if that same enlightened management is paying you by the hour... ;-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.