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?"
...documentation afterwards. That's logic!
Yeah, the more crap we add to the development process, the more we can slow it down enough to actually squeeze some requirements from the stakeholders before _all_ the coding is done.
UML, XML, Six Sigma, CMM, yeah that will all help...
Wouldn't Parrot, or similar approaches that let you code in whatever idiom you feel most expressive in, while compiling down to efficient, cross platform bytecode be the pentultimate achievement? You could add a module for UML and let those crazy Visio programmers write what they wanted while leaving the C Programmers alone?
...But I digress. TREMBLE PUNY HUMANS!ONE DAY MY SPECIES WILL DESTROY YOU ALL!
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...
Please folks, especially if you're doing an ask slashdot, try to either expand your TLA's early on or make them clear from early context. Until I got to the end of the blurb I thought this was about user mode linux...and now, of course, I have no idea what it is. Background links welcome.
(this should answer the question of how I use UML...)
Starting with the obvious. Any other good places to direct the novice and experienced?
One line blog. I hear that they're called Twitters now.
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.
An "Ask Slashdot" that provokes an interesting discussion? That's not allowed! Are we all out of clueless lame-ass questions, or what?
You should follw your own rules. I think you are right. But, I don't really know what a TLA is so, I'm just guessing?
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.
The only time I see formal UML is when it is generated by a reverse engineer tool that spits out UML for what has actually been coded.
If there were some actual useful UML tools I might use it a bit more, but as it stands I don't much care for any of the diagraming tools that are available.
[Set Cain on fire and steal his lute.]
1st try it on the sheet of paper
2nd try it on the blackboard
When solution of problem is clear, you can put it in computer. Whatever way you like, because you understand it. Even UML works.
UML is useless because it can largely not be meaningfully verified, kept up to date, or executed. As a communication language in the middle of a design session a simplified version of it has a place, but there's little point in trying to drive development with it.
I can't point to a project that does everything UML tries, only it works, because state of the art has not advanced there yet, and anyone telling you otherwise is selling you something, be it software or an agenda.
But I do know one thing that you must internalize: If it doesn't execute, automatically, it won't be kept up to date.
The best thing I've found so far is a strong coding style that emphasizes readability above most everything else (none of this "np_doSCRTtrd" crap, give me "mainWindow" or something... even in C++ where this is strongly counterculture), comments for why the code is doing what it is doing, and unit tests to provide and verify specification compliance.
Nope, that's not complete; it is difficult to borderline impossible to unit test everything. But this will take you far past anything UML can do reasonably, so it's a start. (I'm inclined to think the way forward is to make more things more testable; while unit tests have problems with multithreading even in theory, a lot of the practical problems one encounters comes from a lack of testability built into libraries. The canonical example of this is GUI libraries; there is no fundamental reason GUIs should be hard to test... if you could post events to simulate anything the user might do, that alone would nearly be enough, and you'd think this wouldn't be hard...) It's just the best I know, and, like I said, as far as I can see it handily defeats UML in every way that matters to me, so the fact that it doesn't fulfill the promises of UML doesn't bother me, especially as I'm not convinced anything can.
At least somebody should mod parent Insightful. You can't fully design your program in advance, because you're always going to run into issues, and because the requirements will be different when the implementation is done.
This is exactly the trap most UML users fall into, which is why I avoid UML like the plague. Design and document as you code. Hardly any project is ever finished, and the design and documentation shouldn't pretend otherwise.
Please correct me if I got my facts wrong.
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.
Emphasis on the word, try. Most of the time we end up doing it the old fashion way which is that when someone wants to illustrate a complex idea instead of using a neat little UML diagram that half the team will spend most of the meeting trying to figure out, we just draw it on a board with a marker. It's low tech, but it works.
We unfortunately bought into the whole "Rational" line of products and they have turned out to be horrible. It's had many of us pining for CVS and bugzilla.
Click here or a puppy gets stomped!
The idea of having nice pictures of the code has been around for a long time - from flowcharts.
But keeping this pictures in sync with the code requires a lot of effort. In most codebases I have seen, even the comments are not in sync with the code, so you can forget the design being in sync with code.
For UML there are some tools which offer round trip engineering, so it can be less overhead than updating a a design doc every time.
The negative sides I see are
- common tool, rational rose, is a bloated broken, buggy pile of doo.
- The tools are too costly.
- The UML guys seems to have taken a decent idea and mixed in a lot of unnecessary bullshit, class & sequence digrams are okay but anything beyond that will be pain.
- Actually decreases productivity for people in the project, but useful for a new guy coming in.
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.
I use it mostly when I cheer on my UMass Lowell Riverhawks at Hockey Games...and when i check my student email... and when I walk to class... and..oh wait, is that not what you meant? :P
unzip ; strip ; touch ; grep ; find ; finger ; mount ; fsck ; more ; yes ; fsck ; umount ; sleep
"Penultimate" means "next to last." Maybe you just meant the ultimate achievement?
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.
What "I" see languages becoming is more "leveraging" As Joal mentioned when memory managment became a task for the machine instead of the human. Productibity increased. Maybe for programmers to be ever more productive, they'll have to relinquish ever more control over the process? Managed will be 2005's buzzword. From managed languages, to managed frameworks, to smart containers. Soon we'll speak not in the "dot I's, cross T's forgot a comma" manner we do now. But ever closer to the ideas we presently spoon-feed our machines.
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
.. use UML. After having had a few courses about it and some training for a project, I and everyone was highly motivated. Till we realized how time consuming it was compared to its benefit. imho it's just plain unproductive and the better choice is to stay away from it..
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.
It's bloated and complex, not based on any formal principles, and is difficult to use "the right way". For instance if you're modeling a class, do you list every instance variable? What formal rules do you apply to decide? None, it's entirely ad-hoc.
However, it's useful to *communicate informally*. For instance if you want to tell a co-worker the structure of your classes, you can scribble something on a whiteboard.
Look in the Gang of Four book for instance, there are some nice clear diagrams which could be considered a subset of UML. Learn that much and you'll do fine.
DO NOT use it to design your software though! It's BDUF (Big Design Up Front) gone horribly wrong.
How I *actually use* UML is as a mechanism for communicating ideas "live" on a whiteboard to others who are trying to think through solutions in a team setting. And then I use less than 10% of UML's capacity -- mostly just class diagrams, and occasionally interaction diagrams.
I do NOT use it as long-lived documentation, because it goes immediately out of date. The only guaranteed-accurate documentation is the code itself (and not even code comments). Sometimes a high-level diagram can be meaningful for a while, and I'll make one for posterity sake, but mostly not.
How I *WOULD* (like to) use UML is for the visualization of existing code -- to analyze it from a 10KF view; to make pictures that'll help me understand the code and figure out how to improve/extend it. And then I'd throw it away when I was done. Unfortunately this is how I would LIKE TO use it, because pretty much all reverse engineering tools seem to fall short of accurate, or at least "sane" interpretations of what's going on.
I guess the design tool that I would like to see would be a reverse engineering tool, UML use case tool, physical spec tool, and architectural spec tool. All as easy to use as visio and with the capability to export in image or pdf format.
As it stands the 3x5 and whiteboard method are far more useful than most of the tools that Rational provides.
[Set Cain on fire and steal his lute.]
I use UML to design and document apps I write, when it's helpful. Usually for apps it takes longer than an eight hour day to write, and will see change in the future. It provides a birds-eye view of what the app is doing, and how it represents data.
How many open source projects do you see that come bundled with documentation cleary explaining how its internal structures look and relate, and how the program was intended to behave? If you answered "Few to None", you'd be today's winner! Monty, tell 'em what they've won!
UML is a visual modeling *language* used to communicate program behavior and data structure concepts with others (mostly humans), typically in an object-oriented context. As a bonus, there are quite a few visual modeling tools that work with UML. Some emit corresponding code in Java, Python, C++ and a handful of other languages. Some are OSS/FS, while others are proprietary and pricey.
UML is also handy when weaving Design Patterns into your application framework. If you're into designing your applications before you code them, you probably know about Design Patterns and the GoF book. Design Patterns are another kind of *language* for communicating about structure and behavior.
I'm not saying the only way to design an app is with DP and UML, but together they are very effective at communicating data structures, how objects/structures are to be constructed, and program behavior. Which, not coincidentally, are the three main categories of code patterns described in the GoF book.
The main point of UML is clear communication; for DP it's creating solid designs. To create an application that works well (does what's intended, doesn't need refactoring/rewriting when new data formats or behaviors are expected in the future), and is easy for other programmers to pick up (program logic easily understood, relationships between classes and other structures easily identified and grokked), it is good to choose a common language to communicate those things, besides the one the app is written in.
For the folks who pedantically attack UML as being part or product of an authoritarian regime - well, it's just a tool that helps you get your job done, and communicate effectively with others. Sometimes it will get used by hardliners I suppose. The flip side to that is, are you communicating clearly and consistently?
Maybe that doesn't matter to you, but maybe also you would be better off for expanding your personal toolset, and making yourself better understood.
Big Daddy, Johnny, Burp, Aunt Zelda, Scott, Slurp, Big Momma
There is a conflict over territory in what UML and ER (entity-relationship) diagrams dipict. Where they don't overlap is behavior, but UML tends to assume that the relationship between entities and behaviors is one-to-one when actually it is not. My development philosophy is more or less to decouple, or at least not hard-wire at a high level, what entities are used to carry out a specific task. The relationships between entities and tasks is often fluid and not one-to-one, so I see little use in hard-wiring such relationships into a design by using diagrams that encourage it.
Table-ized A.I.
It would have been better if the modder had written a motivation why that product (and method) was bad.
Anyone with answers?
Karma: Excellent (My Karma? I wish...:-( )
A few years later, I did some work for a major aerospace concern that had brought in an army of UML consultants to completely re-org the way they built their flying machines. They had literally wallpapered an entire floor of an office building with UML diagrams. Needless to say, nothing ever came of their delightful illustrations (other than relieving the corporate coffers of much coin).
UML has unfortunately become an industry with lots of fancy GUI tools to draw pretty pictures, purporting to magically generate code from committee meetings. Just the sort of thing that keeps PHB's in corner offices, at least until the customer asks to see the working final product.
UML is good as a starting point; it provides a lingua franca to flesh out requirements, and to communicate those requirements to implementors (I'm esp. fond of use case scenarios). However, it doesn't translate well to the often chaotic world of actual implementation, where performance issues, platform specifics, breakneck delivery schedules, and changing/creeping requirements usually crush the elaborate UML blueprints.
UML is a discipline, rather than a technology. Properly used, it will likely improve your ability ro deliver what the customer wanted. Just don't fall into the trap of assuming its a magic wand that will make the hard parts of implementation disappear.
007: "Who are you?"
Pussy: "My name is Pussy Galore."
007: "I must be dreaming..."
I use Acme::Eyedrops to create UML diagrams that are also the code!
(Okay, actually, I don't do that. But knowing it's possible is the closest
I come to UML.)
Cut that out, or I will ship you to Norilsk in a box.
But not for the reasons you might think.
As others have already noted, UML is largely used as a means of documenting how the code works. We use it this way both during the initial design and later when we've completed coding. However, in recent years, I've noticed much more resistance to doing this. The reason? Many of the engineers believe that having well-documented code makes it easier to offshore their project! So many of them fear for their jobs that they hoard their knowledge rather than document it in a form that can be easily shared. Sad but true.
GML is the only proper tool for these kinds of jobs. It's been through the fire of real projects, streamlined and factored to the essence of the task, and gives these diagrams the legitimacy that they really deserve in the design process.
Big fan of GML.
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?"
Which one has more comments? - No 2, but maybe I am wrong.
Is it the one that's easier to read, maintain, and debug? -No idea, said I wasn't a developer
Does the second have a bug? -NO idea, not a developer
Is the comment correct? _again, no idea, although initially it appears incorrect. Frankly, neither example makes much sense to a non coder, at least to me they don't, not on a glance anyway.
I was asking a question, not really making a declarative statement based on skillset, therefore if by asking a question makes me "incorrect" I pity students everywhere who might have to learn from you somehow-or a coder down the line who has to interpret your stuff. No offense of course, just an observation.
Anyway, with that out the way, it brings up another observation in this code versus comments imbroglio. Why is it that it's one or the other? In a sense I am agreeing with your last that "the code is the comment". Aren't there any code generators that use actual grammatical speech entirely yet? If not, why not? Too hard to build or what? Why should there by code AND comments, why can't the comment BE the code, all the time? Instead, I read about yet another miracle floorwax code language being developed. Seems to me they are all minute and arcane variations on the same deal, designed to be...uhh. what's a descriptive phrase...obscurely counter intuitive and overly rube goldbergish complex.
Rhetorical on my part, I don't know enough to phrase it properly. Just a view from the outside looking in. I know like in the example there are languages that are *closer* to normal speech to use for coding,so that a bonafide coder could glance and see what is going on,comments or not, but isn't the idea of computing the idea that eventually everyone can use it to the fullest, and *easily*?
Just wondering when the next logical step is taken when a code language is developed that exactly mimics normal speech in it's ultimate output in binary compiled form. I know it's a scary thought to professional coders, but hey, automation and better tools and more ease of use comes to every field eventually. I personally *love it* when I get access to a new and/or better tool that eliminates or reduces in time and complexity a drudge chore for me and lets me go on and do something new. Like ask me if I'd rather use A-a scythe, or B-a bushhog when tackling a pasture.
In the meantime I'll let ya'all smart guys with the keyboards wrangle over it (code language flame wars are a LOT funnier to read on slashdot than OS flame wars, BTW, from the perspective of a non coder, it's like listening to people argue over sanskrit as opposed to aramic as to which is "better", ie, sorta silly) and I'll stick to driving ye olde computer bus. And thanks for the work, really! appreciate it! If it wasn't for you guys, no computer use for the kid here. I get enough mechanical headaches keeping various small and medium sized engines running. And next time you might happen to chow down on some chicken or steak, you can reciprocate the thanks back. We all work together *on the planet* to make each others lives better, and also to make a buck for ourselves. I know I appreciate it when someone suggests something entirely new to me as regards my work, I'll stop and think about it, because a long long time ago I learned sometimes some pretty snazzy inputs can be gleaned from someone else looking at what you are doing who hasn't been blinded to the forest by standing in the tress all day long.
After I use UML, I wash my hands. That whiteboard marker ink is messy.
... and never will be. UML assumes that everything can be reduced to boxes. There are things I can say in code, that I would like to have another notation for. If UML is truly "unified," show me the UML (sequence diagrams, in this case) for the following code (explained here):
Better yet, show me the sequence diagram for this function's caller. Or, since Lisp is supposedly dead, how about this:
Want an example in a more contemporary language? Then just draw a UML diagram of, say, Spirit , for instance. The control flow here simply cannot be reduced to boxes. UML can't deal with RAII in C++, or finalize-time operations in Java. UML is fundamentally a decent whiteboard tool for some of the less complicated and less expressive languages. That's all it is. (Except for use cases, which have somewhat more broad applicability.)
...well, weekly maybe. First, throw away any 'official' purpose UML might have had. It's just a way for describing aspects of code design, that's all. So are flowcharts and ER diagrams, etc. I use UML (and the others) both to sketch out ideas as I'm working through them, and as a common language for describing my design to my dev team, or for collaborating with others. If you think your code doesn't need describing, then it's either very simple, or you're very wrong. It doesn't need to be described in every detail, that's the job of the code & in-code documentation. But if anybody ever has to come back to this code in a year -- even yourself -- then they're going to want to know how your objects fit together, or how that little trick you used to get the database working worked again, or what that bizarre recursive function you cooked up was supposed to do, or how those threads interacted... Yes, you can go back and look at the code. For instance, the project I'm currently on has about 2000 source files written by about 30 different developers over 5 years. There's a half-dozen subsystems running on different servers, and they all talk together in ways that no one ever bothered writing down. Sure, _you_ go look in the code. I'm going to get drunk. If you're writing a VB app with a fews screens, then a couple of use cases and some screen shots will probably be all you need, if that. But if you can apply the term 'non-trivial' to any aspect of your system, then it needs to be designed before time, and documented throughout the process. If you don't...well, then I'll be at your ex-place of employment in a couple of years to clean up your mess.
UML is used only for notation and documentation. UML isn't context-free. Unless we're talking about Natural Programming Languages, UML will never replace languages like C++, Java, etc...
UML is useful for when you're working on a large project, that may be used across sites or even across companies if you're sub-contracting the development of your system to outside firms. I think its better at giving new developers something easy to digest before looking at the code. If you're subbing out work, it allows you to create high-level interfaces and hand them out to your sub's development teams to ensure that integration is easy (i.e. everything compiles and only that). They have a reference to work with and you may be less bothered with questions from the sub.
UML, like most other other software engineering fads exist mostly because groups like OMG want to push new consulting fees to large commercial companies, publish more series of books and create forums for them to lecture to (and charge fees).
Most large companies are abusing the hell out of all this software engineering sugar. Business Analysts authoring UML diagrams, not knowing exactly how this will translate into system. This ignorance, which is not their fault, its their managements fault, can cause hell and resentment among the developers.
Overall, UML is useful, but its not a save-all. You need guidelines to make it useful, and you need to refine them constantly. Tools are another issue. There are few that bridge the programming with the designing intent that UML and these tools attempt to provide and do it well.
When I read stuff like the above I'm inclined to think a project went sour, and blame was put to rigidly following UML with no clue why, how it works or what for. Hey we did it the right way and still failed, what gives?
Well, here's the next silver bullet, I mean paradigm. For some of the controversy, read Grady Booch'sDec 3rd article. Actually, DSLs look interesting, MSFTs proprietary "Software Factories" do not. They lament the fact UML is too limited. It seems that if you dislike UML, you'll really dislike their "vision".
I still have a lot to learn - I went to a small liberal arts college down South.
My tiny brain says this is not a debatable problem - kind of like debating whether the Cowboys won last week when we only have third quarter scores. Either this is something that the computer science profession can figure out with existing CS knowldege or some PHd candidtae can research in a dissertation to see if UML can fully map the abstractions, representations, etc needed by computing languages.
DirtySouth2005
There is the model driven architecture (MDA) issue (that isn't being talked about here much).
There is the waterfall vs. agile vs. sloppy issue.
There is the authoritarian martinet boss vs. childish coder run amok issue.
The "the tools suck so UML sucks" issue.
And finally, there is the "It sucks so I'll never use it" vs. "Use the right tool for the job" issue.
MDA first. UML is only the first part of OMG.org's attempt to revolutionize software engineering. I find MDA silly beyond words, and so I will not do it justice. Go visit OMG if you are interested in their side. The MDA folks want to be able to build universal models that get reused, transformed to fit domains, manipulated by tools to do all manner of wonderous things. I personally think they are having wet dreams, but it would be great if they could pull it off. That said, if you fully drink the OMG kool aid, you wind up thinking that all we need is a few high priests of models and really smart tools. right.
As for the lifecycle issues, all of us who have been on more that one project know that the waterfall doesn't work; the "let's just write stream-of-consciousness code and screw everything else" doesn't work; and XP requires especially disciplined troops to make it work at all and then only or relatively small projects.
What is also clear to anybody who has ever done maintenace, is that unless your code will never be used by anybody but you or it is small enough and well enough written to be understood by a complete noob before lunch the first day he looks at it, it is unprofessional not to document your design. It is also stupid to tackle anything but the tiniest projects without a design (and I count XP's emergent design as a design). So what are you going to use to express your design? How about the notation that all the books about software now use -- UML?
I have worked for more authoritarian bosses than I care to remember. But I have also worked with too many nightmare developers who either simply didn't know what they were doing, had emotional problems, or were just jerks. This has nothing to do with UML, these same types were poinioning the same wells in the days of FORTRAN.
Tools. The three amigos are the worst possible thing that could have happened to UML. They all work for Rational, so bosses think that Rational must have the best tools. **gag** Go look at Magic Draw, or Together, or Embarcadero Describe. I've had reasonable luck with all three. BTW, the three amigos are also behind MDA. I haven't been paying close attention to UML 2, but it seems to me they are making UML less useful for real work to make it more friendly to MDA.
Sometime UML does suck for a particular job, or a particular implementation of UML sucks. That doesn't mean that is should be forever foresworn. It is a good tool for some tasks. Use it for those tasks. If the boss is so stupid as to think that the teams' best guess at a design at the start of the project should be cast in stone, then it is immaterial how you express your design, cuz you are screwed no matter what. (but don't be so silly as to neglect doing any design just to spite a stupid boss)
Many software projects fail because coders/managers do not actually understand what problem they are really trying to solve. UML in theory, but typically failing in practice, tries to address this. Pour in plentiful use cases and some eye of newt and out pops (not unlike from the Finite Improbability Generator) a complete and sparkling model of the problem. In reality, the input is likely flawed and incomplete. The result is a tool that is a dangerous crutch cicumventing actual understanding of the problem at hand, while generating management pleasing (and I'm a manager) pictorial output. Add to that a big learning curve just to grok the syntax, low usefulness to communicate with outsiders (such as marketing people), and high overhead as requirements change or become more clear make for a negative ROI for this tool. It is clearly a fad that needs to go away and make room for some better formalism.
I'm a computer engineering student and for that they make us take some comp sci courses. In comp sci 2 and especially 3, they stressed UML very much. For each large assignment, we had to do class, state, and relationship diagrams. I'm torn if it was a waste of time. On one hand, it wasn't difficult and it was a good way to get an idea of how to start the program. On the other hand, we were learning UML as we were learning C++ so we'd end up changing so much when coding that it wasn't much use afterwords.
Making these diagrams was a pain too. I tried many programs such as Dia, Kivio, Umbrello, and Visio using crossover office. None worked that well which was frustrating since as a student, I'm not going to shell out big bucks for a real program. Btw, visio was given to us for free from good ol' microsoft through some student program.
In my very limited experience, we just used it to hammer out an idea for a program to show class relationships and not much more.
UML is a great tool for providing a common notation (what it was originally intended for from what I understand). Using it pragmatically takes experience. Programmers tend to model their implementation a little at a time and miss the point of system or application modeling. Where UML can be used successfully to generate code (overcoming the problem of keeping the diagrams and documentation current, a common problem cited by programmers who want to code, not design or document) using tools such as those from Kabira (www.kabira.com) or Accelerated Technologies Bridgepoint (http://www.projtech.com/). I would recommend spending some time at the OMG sight (www.omg.org) and read up on MDA and Executable UML. Oh, and sprinkle your use of UML with a healthy does of pragmatism, i.e., if it doesn't bring any value, then don't do it based on the modeling methodology you choose to use (UML != Methodology; RUP, OMT, OOSE, Booch, Fusion, et al. would be methodologies).
But your mileage may vary......
P.S. In my experience, the rush to code can be characterized as always having time to do it over, but never having time to do it right the first time.
I never jump straight into coding, unless it's a trivial write-once program that'll take an hour or less. I design everything non-trivial ahead of time. I draw a lot of diagrams and write a lot of psuedocode. It may at times have strong resemblance to UML, but only because UML incorporates many (but not all) useful design methods. I'm not the kind to jump on every bandwagon that comes around. I have so much reusable framework code written and thoroughly tested, simplifying the implementation, that I can rapidly produce prototypes or make sweeping changes to a project as needed. My resulting code is very short, readable, and maintainable.
It doesn't matter whether you use UML or other design tools as long as the outcome is a clear, correct design and high quality maintainable code written in a timely manner meeting every need and want. Ultimately, putting too many constraints on your thought and creativity can do more harm than good.
I found UML to be very awkward. It seemed most people would adopt it because it sounded good in a "best practices" way, but, in practice, it didn't get used very effectively. Class diagrams can be useful, for example, but, unless everyone in the room understands what the different styles of arrows mean, their usefulness can be severely limited. I also found the "actors" style of thinking never really penetrated my skull, for some reason.
The #1 biggest thing that bothered me, however, is that UML sets up whole analysis phases to be literally thrown away. Why spend the effort to make nice-looking use cases when they basically get thrown away? Isn't that what white boards are for? More extensive requirements are hard to express in pictures, anyway.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
I have. And way back into last century even. :-)
And this is where I'll have to strongly disagree with you. Even "Extreme Programming Installed" (a book I personally belive wonders off a bit from Beck's best XP) says to use UML.
Additionally, some of what I've seen in the best projects is the use of good Javadoc, DOC++, Doxygen or some such comments. The best time to write those is while the design is fresh in people's minds, such as in writing up initial tests or first writing each class. Additionally, it's much easier to keep up to date, and helps greatly as people need to go in and refactor code. Oh, and Eclipse has good Javadoc support, and having Javadoc comments helps it work even better.
Of course, I've gone Extreme myself on different projects by writing Docs in XML. Just poke a single XML with different XSLT stylesheets and get end-user API documentation, internal implementor guide documentation, and full test case source code all from that single sparse XML source. (But especially with all the workflow benefits one gets in Eclipse from having proper Javadoc comments around, those are well more that "disposable").
Here is my $.,02 for what's it worth.
If the following sorts of things apply to your project the you are good candidate for UML:
1) I would gladly triple the costs in exchange for halving the number of bugs
2) There is almost no value in having the project complete early. On the other hand we need virtual certainty of meeting the conservative deadline we generating in the planning stage of the project.
3) The costs of the software are overwhelmed by the costs of XYZ (where XYZ = marketing the software, getting it certified, the cost of how it gets used...)
4) The cost of a serious bug is a large percentage of the cost of the project
5) At the higher levels of the project we need to budget in terms of dozens/hundreds of man years for completion. Traits of individual developers are irrelevant
6) No piece of code gets into a build without passing through at least 6 different stages involving independent or mostly independent groups
7) We already have a highly controlled environment but the size of our projects is simply overwhelming the abilities of the dedicated (build, analysis, code control..) staff to understand what is going on.
Conversely if the following apply it won't work out:
1) We are under a tight deadline
2) Individual programers have a feeling of ownership about their sections of the code
3) Management is highly cost conscious
4) While no one likes bugs its hard to imagine any single bug which is likely to get through would be serious enough to warrant increasing the total cost of the project by 10%.
5) We have kind of a loose environment and we are hoping that UML help us to tighten up a bit.
Not that I know of -- they are too hard to build. Natural language is very different from the artificial programming languages. In fact, understanding natural language is one of the most difficult of the sub-fields of artificial intelligence. Natural language is vague, full of grammatical exceptions, and relies on lots of contextual information to understand a sentence. Obviously, all of these spell disaster for a programming language, which must be absolutely unambiguous.
It might be possible to specify a more "English-like" (or insert the natural language of your choice) programming language, but there would be a lot of rigid grammatical rules that aren't like regular English. The result would be an unwieldy and verbose programming language that nobody would be able to remember, since it is too close to real English (hmm, do I need to type "each object in the container" or "every object within the container"?)
If my enemy's enemy is my friend, what happens if my enemy is his own worst enemy?
Anyone here old enough to remember that?! Little fluffy clouds: made for great "informal" diagrams. IMHO, UML just took the whole design notation too far.
You say you're not a developer - well, there are already enough people churning out "write only code", so kindly keep it that way.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
However, UML as a whole involves a much, much bigger business scope, and that can be a nightmare. I was once part of a project that had one person in charge of keeping the use case document up to date. It was never up to date, because no one who was actually doing any of the work cared about it -- it was an after thought, not unlike doing all your coding first and then saying "Oh, yeah...test cases." And of course we all hated the use case person who insisted that no decision was final until she had properly documented the change and gotten sign off that everyone was now on the same page. Imagine those meetings. Every engineer, marketing person and project manager agrees...but we have to wait a few days for the use case person to document what she thinks we said.
Is it good to have such a document? Sure, certainly in theory, much like it would be nice to have a single grand unification theory of physics. But that kind of talk does not meet deadlines. Go build a house. You will start with architectural plans. Then the builders will build it. When you're done, see how many times you changed the plans on the fly to accomodate problems that had to be solved on the spot.
www.HearMySoulSpeak.com
A lot of people here mentioned wanting a product where modifying the UML modifies the application. But what about the other way around?
Does anything out there generate UML (or similar representations) from actual code-paths chosen by the application when it executes?
(How would this be done? Perhaps using a specially instrumented runtime environment/JVM/glibc etc...)
A product with both functionalities would offer design round tripping.
Wrongo. Your code should also document a bit of why. It's just lesser languages (compared to e.g. Lisp) make it too hard to form abstractions and "little languages", and get all caught up in the how. Comments should be one per function, and usually the docstring (lisp/python runtime-available commenting) should be totally sufficient.
I like UML as a type of diagram, similar to database relationship diagrams. Unfortunately, while DB diagrams are spat out of database programs, most UML is edited by using crappy tools like Rational Rose. The cool thing with DB diagrams is that you can generate up to date diagrams right out of your database. Ideally, you should be able to do something similar with UML.
I'd like to see the ability to add markup to code, to specify UML entity relationships. This markup could be like Javadoc comments or C# attributes. Then you could have a tool generate the UML right from the code, have up to date diagrams all the time. That way, when the PHBs ask you to work on the UML diagrams, you could actually be working on the code. It amazes me that noone does this yet.
I can say that Rational would not like it; it pretty much reduces their entire product like to a Javadoc like tool.
I'll occasionally diagram ideas when thinking about how to implement something or design an API, or sometimes in documentation. Dia has some nice looking boxes in a category called "UML" which I use sometimes. Also, Doxygen can generate collaboration diagrams that look like UML diagrams. Mainly I just need some boxes and arrows. All that other stuff is not that useful.
Maybe it's useful to autogenerate IDL or someting, but I've always found that to be a completely broken concept entirely.
Reed
VOS/Interreality project: www.interreality.org
Like COBOL? :)
Jeez, just typing the name sent chills up my spine.
May the source be with you!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
when it stops being common sense, it stops being XP.
So, WRT to UML or not UML, well, of course you need to have some kind of design, preferably on paper, before you start coding. The real issues are the scope and the finality of those designs.
The way I read XP, the scope should be just sufficient to solve the problem at hand, and not so large that altering the design to handle expanded requirements is politically or emotionally impractical.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I see a reasonable number of useless comments from people that haven't used OOA/OOD language, but like to suggest their hypothetical ideas about the problems.
Having used UML, I've found that UML itself per-se isn't the most importnat thing, what was really the killer was Rational ROSE with UML and code-generation. The reasons are:
(a) the first pass UML diagram in Rose helped establish the "rough" design model: a pretty close OO diagram to help estimate complexity and amount of time for implementation.
(b) the code-generation is fantastic: you work through your architectural layers and components, to flesh out that initial design (and yes, 20%-40% of your rough design will be thrown away and reworked) and implement code, refactoring and adjusting as you go, in tandem with constructing unit tests to verify.
(c) afterwards, the UML diagrams in ROSE and code-generation make it easier to refactor and add/change functionality, and for new hires, the diagrams are the best documentation for the design: because they are the design, and are in sync with the code.
Um, YOU left out the why!
...)
... replaced by the appropriate how, possibly calls to other functions like check-article-master-shipping-weight
If it's to validate the article master document for delivery, then you'd write
(defun validate-article-master-for-delivery (article-master)
with
Lispers aren't scared of long names. We have tab completion...
I'm currently a Computer Science Engineer working at a major company for less than a year. I've used UML diagrams in college and the workplace. My overall expierence is as follows: 1) Create the UML model for the comceptual phase with just enough detail to cover all the important topics. 2) Update the UML model as the product moves through the preliminary phase. 3) Create a final UML diagram for each released version of the product.
"As far as for making commentary so that unskilled people can understand what the code is doing, what's the point?" --because I don't think there's any such thing as a black/white skilled and unskilled exact dividing line with people who do code. For every coder there is his or her skill level. There are beginners and old timey gurus and everyone in between. And more times than not, the gurus code fails it sometimes and then someone else needs to go and fork around with it to get it to work, including non coders. That's why. You can see it here sometimes (heck, more than sometimes all the time) on slashdot where some code snippets are being discussed and you can see a wide range of how to do it and example to counter example to further counter example, etc, with all the replies being done by "skilled" level people.
If it is ambiguous at that level,back down the road to the even more unskilled it gets increasingly more difficult to understand what is going on. It would seem better commentary might help alleviate that.
The whole idea of foss is that people other than the original coder will be working with this example code, at who knows what skill level. They could be raw beginner to grizzled veteran. Just saying "well, if you aren't exactly like me in skill level,therefore knowing exactly what is going on here instantly and intuitively, you have no business trying to understand or adapt to or alter from this code" doesn't foster increasing sharing and better code coming out and more involvement with more people.
I would imagine that is one-not all but one-of the major reasons you see so many examples of very similar projects being started and worked on. There seems to be some coders mindset there that cooperation isn't as important as going it alone in a lot of cases. And it's also a deal where even people who aren't coders by nature or profession still have to ocasionaly go into some obscure files and fix something. I know it's happened to me a few times,latest two weeks ago, and the *only* way I was able to fix my serious problem was from the comments in the code, otherwise I would have had no idea where to even start to look. All major googling got me was where to maybe look, that was it, and even that was vague enough to be major league confusing. After I found something that looked suspicious, I took a chance on doing some very basic modifications, which apparently worked. If there had been no non-coder human readable commentary there was no way in heck would I have been able to fix it, none,nada, zero. So, I guess that means that I should have just remained with the broken stuff (broke my firewall and couldn't dialout either) because I'm not the same skillset as the writer of the code? Really, that's what you suggest? How awfully nice! Naw, don't think so. I appreciated the comments because it was non coder human language readable, if it hadn't been..tough noogies for me. Sorry, don't need the elitism. It would be like -just an example picked at random-you having the plumber come over to fix some problem, he fixes it, you ask him what he did, he replies "sorry, you aren't a master plumber, you don't need to know what I did, nor could you understand it". How would you like it someone said something like that to you?
Hope my point is made more clearly now. The main reasons, I read the IT section and comment here occassionaly are -I hope to better my understanding of what the heck is going on with apps sometimes because user manuals and man pages still mostly suck bigtime, and two, to help nudge the various coders mindset more towards cooperation and reducing the barrier to entry with code in general. To help eliminate this obvious curse that exists in software land of "N developed IMBY so it isn't any good". And that's because I thought the whole idea was to tear down fences, not build new ones.
closer to what I was thinking. Eventually, flash forward to the mysterious future with flying cars, I would think it would be spiffy if there weren't any traditional hard coded traditional apps, instead to have "create what you need to do on the fly" software, by just about any user. And that software would then go and coordinate with what hardware resources are available, at that exact point in time, considering that computers then would be the entire network, not just the stand alone box we have now. The transition *might be* in these various languages and a universal translator or parser of some sort.
As an PM I tend to use UML as a way of communicating with the client. Use cases are a great tool for explainig what a system will do and how someone will use it. Together with some schematic screen lay-outs it speeds up the process of designing and getting the design accepted by the client.
Further in the process the role of UML decreases, mainly because of 2 reasons:
- All UML tools I know are too cumbersome. (Rational Rose, Visio)
- Growing insight amongst the developers always leads to little (or not so little) changes in the way the design gets implemented. As far as I know it's impossible to update the design according to these changes without investing fast amounts of effort, resources and money. Reverse engineering certainly isn't the solution to this.
I don't use it at all because I don't like it.
I don't like to think like that. With UML I tend to overengeener stuff.
Right now I prefer to refactor on the go when I discover something I didn't thought off before (the refactoring can take time, but I do take the time to do it cleanly)
UML is not a code-generation language. Even though many tools have this as an option, don't use it. Just don't go there. In fact, stop using Rational Rose and Argo and start using Visio and/or Dia instead.
If you're diagramming every method for every class, you're diagramming far too much. UML wasn't meant for that level of detail. If you find yourself obsessing over access specifiers in your diagram, you need to cut back on your caffeine intake.
Make your class diagrams high level. Capture the broad design of the software, not the details of implementation. This may require you to ignore most of the bells and whistles Rational gives you.
If you're not writing the requirements, don't create the use case diagrams. Let the bubbleheads do that. But do verify that the use cases are correct and sane.
Use different types of diagrams as appropriate. A device driver would never need a class diagram, but a state diagram would be invaluable.
Don't blame me, I didn't vote for either of them!
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 just finished taking a class on UML that lasted 3 months...what a pain in my *$$! However, UML does have it good points. In a high-level easy to explain to you're less intelligent co-workers way it gives a great WSIWYG view of the project so customers can agree to the solutions the techies are giving or not. It allows you to plan without having to go back to the drawing board later. As far as the ultimate goal of UML where software can be just classes that are used over and over again and never have to be changed I'm not sure if thats possible and even if it was I doubt that most people are going to be able to patent their own little classes and the code associated.
No text
I am currently a software technical lead at a well-established avionics company and have been involved with many UML-related discussions, training classes, meetings, and FAA certified projects, in addition to smaller at-home PC-based projects. I have taught UML and the Unified Process in house for more than a year and have also read and applied many of the key books on object-oriented design, business modeling, use-case modeling, the Unified Modeling Language (UML), and the Unified Process. I've seen and used UML used in quite a variety of ways (pc game, web-based genealogy database, quality system business modeling, embedded product design, embedded graphics driver design), with a variety of goals in mind, with engineers ranging from hardcore embedded avionics guys to throw-it-together PC app developers. On some projects UML has been very successful, and on others it has failed, but before I mention why, let me first address a misconception I've seen as I've read the posts above.
Many engineers new to UML mistakenly think that the UML dictates a process. However,
The UML is not a process, it is a modeling language
In other words, it isn't UML that dictates the activities and process of your software development. That is instead the job of a process like the Unified Software Development Process, or the standard waterfall, or rapid prototyping, or Extreme Programming, or DARTS/CODARTS, or structured analysis & design, or some other customized process. UML is a language for capturing the models and views of a system independent from any process your project may choose to follow. A process (such as the Unified Process) will customize and extend the available UML modeling elements and define the activities and resources necessary for developing those models. So, when you are having process issues (such as using too much of the UML or fleshing out too much design before starting implementation), don't assume that it's the fault of the UML--it is probably instead the result of a bad choice of development processes.
Strengths and Weaknesses of the UML
From my experience, UML excels at specifying requirements, documenting high level design, describing both the static and dynamic architecture of the system, highlighting core structures and key interfaces, bridging the gap between requirements and design, bridging the gap between business modeling and application design, bridging the gap between database design and application design, and facilitating communication between software developers and the users of the system. (I've actually used it in all of these ways.) UML encourages engineers to think through the problem before hacking together a solution. This doesn't mean that the design should be set in stone first. The requirements and design can and will change, sometimes significantly, over the course of a project. However, I've seen enormous gains in both quality and efficiency when the project team has done a prelimary design of the core structures first in UML, then tried to code them up in C++, learned more about the problem, revised the design in UML, then tried again. Sure there's a cost to documentation but it's cheap relative to the cost of getting the design wrong in C++. One last strength--UML is capable of supporting the development of a multiple layered system, even when that system spans business processes, multiple embedded products that must be integrated together, individual cards with separate software in those products, the layered subsystems in those cards, and on down as far as you care to go. Few if any other modeling languages could say the same.
UML is not so good at documenting low level design except when a certain complex key area needs to be discussed in depth with multiple engineers; "self-documenting" code with appropriate comments is much better at documenting low level design. I have also not seen much use yet for node or component diagrams.
In all the projects I've worked on from avionic
Start with Use Case diagrams, Activity diagrams and Component Diagrams.
l
The order is arbitrary (depending on your knowledge about the future system and your UML skills).
The goal is to have -- before you code:
a) Use Case diagrams which roughly capture what kind of actions the users can do with your software.
b) Components (either planned libraries/dlls or database tables or executeables or configuration files or just imagined "partitions" of one big executeable) where every use case is assigned to a component. That means the business logic for that usecase will later be in that "partition" of code. It makes sense to divide the components up into business components, data access and communication components and gui components (usually a use case is then realized as logic in the business component and also in a gui component for interaction)
c) Activity diagrams for the complex use cases describing their controll flow.
If you do not do a), b) c) above you can not write big systems anyway (except you have 20% factor 10 coders (The Mythical Man Month))
After that is done you pick one use case or two, depending on team size, make the class diagrams for it, generate the code for them and fill out the empty methods with your code.
If you have "scenarios" (that are user acceptance test cases) or XP user stories, make sure they conform with the activity diagrams and make a sequence diagrams as needed for them. That helps in finding the needed methods for you classes.
Use a tool that supports round trip engineering so you can import that code back into your model. So the "private" methods you "invented" during coding get pulled into the model.
Write your unit tests (better user acceptance tests based on the activity diagrams) and import those also into the model.
When needed generate the SQL statements to create the DB tables and/or the DB access components.
Is your application a protocoll driven, e.g. communication, robotics or persistance heavy, you probably might need state diagrams. A state diagram usually refers to a single class or a few connected classes.
Here is a easy tool for UML sketching, it is not usefull for codegeneration etc. but toi get the first ideas how to use UML its probably the most simple one: http://qse.ifs.tuwien.ac.at/~auer/umlet/index.htm
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Exactly. :)
If my enemy's enemy is my friend, what happens if my enemy is his own worst enemy?
For me, UML is for expressing requirements - you are not designing your program in advance - you are expressing in a formal way what you want the program to achieve in advance - if your requirements are non-complex and you can accept escalation (scope-creep) then go ahead and use rule of thumb, works fine for lots of people, but for managing huge projects, the problems rarely lie but rather in the expression of requirements. Even for a simple project, interconnected use cases with pre and post conditions is a far better than english prose. It also gives you a nice mental model to hang the code off to make sure that you are solving the right problem. For more complex behaviour UML Activity Diagrams help greatly, the combination of use case and activity diagram creates an excellent way to decompose behaviour. Adding class models with constraints goes even further defining data and rules that give a head start into the development. The rule is to capture the essence. That requirements will change is a given fact of life, but with an MDA approach, the impact of those changes have a better chance of being managed and costed properly. Best thing is that once you have completed the requirements model, you have a re-usable system description. Since technology changes are v. expensive re-inplementations of existing functionality on a new platform, the base requirements in a non machine/language specific form are worth real and serious money to your company. Leave development for the developers (or in XP, RAD or @home, for when you don your developer's hat). Use UML to express requirements and let the programmers work out the best implementation with current tools and tech. - that's what they're paid for. This is the fundamental approach of MDA (model driven Architecture) - though I reckon the OMG's MDA approach might go a little too far down the RTE (round trip engineering) path to give truly useful expression of requirements. So the UML models tied with a good requirements system (we're using Telelogic DOORS - there are many others, but DOORS came out top for our needs) now, back to modelling the requirements for a requirements system - talk about fead huck...
* Temp! due to errors loading master, approximate shipping weight
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
There are two or three versions, and running in a UML environment works quite well for bother userland and kernel/module development. Its also great for 'testing' unknown software for side effects, being able to isolate the environment is really nice.
think before you write, it'll save me moderator points.
We're artists. Why should we bring our selves down to the level where we're dictated that we should wear white shrts with chains dangling from our necks. Enterprise freaks can sell their souls but it doesn't say anything about the way and success with which they get their jobs done. We'll have it knocked out, tested, running and interfaced, while they are all still drawing little stick figures in their use-cases.
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.
You're making an assumption that one can't understand the structure of their code without seeing it visually. This is similar to saying that one can't understand the plot of a book or interrelationships of characters without seeing it as a flow of bubbles & lines.
they 're still telling me it's too early to make an UML diagram because "the structures change too much". (WTF?!?!?)
WTF indeed. a UML diagram is merely a visual representation -- one can do it any time. Though they may have a point if you intend to do it by hand vs. reverse engineering the code & massaging
-Stu
I once worked for a company called Intellicorp. Many of you UNIX geeks may remember a product thay made called OMW. Kappa was their main product which was an OO management system used to produce OO C programs for the UNIX environment. OMW (Object Management Workbench) was a UML tool that sat on top of Kappa and allowed a user to create executable UML diagrams. The big flaw came with the realization that there were no methodologies that could describe a project completely. This gave rise to the idea of CAM (computer aided methodology). Intellicorp's big idea was that programmers should describe the project through some sort of english like meta language to the computer and the computer would create a UML appropriate to the project.
Obbviously this is a ridiculous waste of time as the timeframe for describing the project and producing the UML was generally twice as long as most shops have to produce and test a project.
Alas, it seems that OO programmers today who have never worked with proceedural languages are helpless without there UML diagrams.
A piece a paper and a pencil can do the same thing for you as UML. After all, nothing replaces documentation.
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.
I flip the page in the spec for the new project, and am confronted with an utterly bizarre diagram.
"Can someone explain how this is supposed to be interpreted, please?"
"It's UML!"
"Okay... can someone explain how this is supposed to be interpreted, please?"
"It's UML!"
"Okay... and it is better than a simple flowchart why?"
"It's UML!"
"Okay... and it is better than a simple flowchart why?"
"It's UML!"
"Okay."
Idiot. Validate means to "make valid". Correction can be a part of a validation process.
And like I said, you didn't SAY why you were doing it, so I assumed it was "for delivery".
Correctness and efficiency is to be found by MINIMISING THE NUMBER OF TIMES THE IDEAS BEHIND THE CODE ARE COMMUNICATED, not in communicating them especially well. No communication is the best communication - for instance a user that programs their own perfect tool. If you can divide a project into mini projects - one for each programmer - who is in charge of taking the mini - project from inception to completion you will do many times better than trying to create an assembly line using uml. Each step in the assembly line will have to duplicate the work of understanding everyone else's ideas before they can add their part to the whole. And the buck stops with the last programmer on the line who has to translate untested ( you can't test UML, only code ) ideas into working code.