How Do You Use UML? 219
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?"
Code first... (Score:4, Insightful)
Insightful (Score:5, Insightful)
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.
Re:Insightful (Score:5, Insightful)
Documenting code? Hah! :-)
Re:Insightful (Score:2)
UML is a notation system, not a methodology. The original poster is basically asking what methodology do /.ers subscribe to in their use of UML.
Here is an example. The RUP methodology prosribes that UML documents are living, iterative, and incremental. They are living in that you go back and update the UML diagram when you discover a change in the design while coding the classes. They are iterative and incremental in that you start a diagram with a focus
Re:Insightful (Score:3, Insightful)
Just because design cannot fully predict every detail and requirement change doesn't mean that the opposite extreme is better. The problem with your suggestion is that when working in a team, there are design changes that you simply cannot make without breaking somebody else's code and assumptions. So clearly, design cannot be entirely static after some "begin coding" day, nor can
Re:Insightful (Score:2)
no, you do need to doc (Score:2)
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
XP is just common sense, enforced (Score:2)
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.
Re:Code first... (Score:2, Interesting)
Re:Code first... (Score:2)
UML is *NOT* Documentation! (Score:4, Interesting)
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 [freepascal.org]. 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.
ANY language isn't 100% efficient... (Score:4, Insightful)
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?
Re:ANY language isn't 100% efficient... (Score:5, Insightful)
Wouldn't really work. There's more to a language than syntax alone. Languages have fundamentally different ways of representing things. Think static vs. dynamic, classes vs. prototypes, objects vs. primitive types, first-class functions, tail call elimination, overloading,
In the context of Parrot, problems are already arising from the way Perl and Python deal with things. We know from history how well calling conventions are adhered to...basically, C and assembly use one, C++ uses a bastardized variant, and beyond there, chaos reigns.
Microsoft is on the right track with
Re:ANY language isn't 100% efficient... (Score:3, Informative)
They are adhered to very well when provided at the operation system level very poorly when left as an option. VMS being a great example where calling conventions and complex datastructures are defined at the OS level. The result is that a C function is callable in Cobol, VAX Basic, Fortran... and vice versa.
Re:ANY language isn't 100% efficient... (Score:2, Informative)
Deciding how to pass the parameters and the return code (the important things about a calling convetion) is up to the compiler. This can happen on the stack, in registers etc. in any order.
This is why you have to use such things as __declspe
Re:ANY language isn't 100% efficient... (Score:2)
That would be bad. A companies depend on software and some type of control must be set up. Standards for languages, documentation, and even how the source code is stored. You never kno
UML-ish (Score:3, Interesting)
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.
Re:UML-ish (Score:4, Insightful)
Re:UML-ish (Score:2)
You're not alone here. Sounds like you're close to 'UML as Sketch' [slashdot.org] as touched on in comments here [slashdot.org].
Re:UML-ish (Score:2)
You are just plain wrong. I've used UML to design and implement low level device drivers for embedded platform with C++ autogeneration. There's nothing in UML that causes it to produce bloaty code, and there's quite a lot of richness with the right tools (e.g. Rational ROSE) to customise the C++ code that's generated.
This has nothing to do with UML, but has more to do with you as the designer: do you know how to design performance device drivers or not
Re:UML-ish (Score:3, Interesting)
Alphabet soup.... (Score:2, Informative)
(this should answer the question of how I use UML...)
Re:Alphabet soup.... (Score:3, Informative)
Unified Modeling Language (UML) [wikipedia.org] is a non-proprietary, third
generation modeling [wikipedia.org] and specification language [wikipedia.org]
What's a TLA? (Score:3, Funny)
Re:What's a TLA? (Score:4, Informative)
It stands for "Three Letter Acronym."
Re:Alphabet soup.... (Score:2)
This is one of the things an EDITOR (the real kind) will point out to the author. This being the Dot, you get what you get, so SDSUAFO.
Re:Alphabet soup.... (Score:2, Informative)
Re:Alphabet soup.... (Score:2)
Well, I'm definitely not trying to troll [ic.ac.uk] here or anything [ic.ac.uk], but in this instance I'd be willing to give the poster the benefit of the doubt on the TLA [ic.ac.uk] use here. Given the target audience (Slashdot tech-heads), and the prevalence of UML [uml.org] in the tech field (among other things there are literally hundreds of available books on the modeling language, but no easily found ones on User Mod
Re:Alphabet soup.... (Score:3, Interesting)
Well... if you want to get into pdeantic details... the <abbr> [htmlhelp.com] tag is probably to be favored. The W3C spec spells out the difference down in section 9.2.1 [w3.org]. Of course, finding out which versions of which browsers support which tags is another problem altogether.
BTW, I find the WDG's guides [htmlhelp.com] 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
I use it to select projects (Score:5, Interesting)
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.
And I Use It to Weed Out Staff (Score:5, Interesting)
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.
Re:And I Use It to Weed Out Staff (Score:2)
By the time I'm finished with the rough model, I basically have a list of tools to make and fit together in order to create the finished program. Of course, this do
Re:And I Use It to Weed Out Staff (Score:2)
...modelling, used correctly... (Score:3, Interesting)
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:
Re:I use it to select projects (Score:2)
It's not that there's anything fundamentally wrong with UML, but UML seems to be the lowest common denominator used when slinging around bullshit.
Hey, if you don't want to learn how to program, but you want to tell a bunch of programmers what to do, learn how to draw squares with arrows off of them and tell those no good programmers what to do anyway!
Re:I use it to select projects (Score:4, Insightful)
Its a communication tool. Thats all.
Its like saying "If the business analyst wears a white shirt and tie, I'm out." or "If the specifications are in New Times font, I'm out."
Re:I use it to select projects (Score:2)
I think you're wrong: it's a design tool as well (you could be pedantic and say that it this also makes it a communication tool, but come on!). Seriously, UML as an OOA/OOD helps you scope out and bound the size and complexity of the design, so you get a clearer idea of what kind of time/effort it'll take to realise, and what order of magnitude bugs/issues you'll have to deal with later.
If you're only using UML as a communication tool, you're seriously underusing it.
Re:I use it to select projects (Score:2)
It doesn't to it by itself, like what an compiler does. It takes a person to read it an then extract this sort of information from a standarlized form. So UML is a communication tool.
What does UML produces? Documentation, which is a communication tool.
Re:I use it to select projects (Score:2)
What? (Score:3, Funny)
Re:What? (Score:2)
I avoid it like the plague (Score:4, Interesting)
When I left the company in April of 1999, we had made no signfigicant progress on the project.
Re:I avoid it like the plague (Score:2)
If you put all those hours into x number of 10-hour days, on the other hand, you would certainly have accomplished more.
Re:I avoid it like the plague (Score:3, Insightful)
Not so much (Score:3, Informative)
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.
Re:Not so much (Score:3, Interesting)
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
Rational kool aid (Score:2)
I guess the design tool that I would like to see would be a reverse engineering tool, UML use case tool, physi
Re:Not so much (Score:2)
Well, because at that point, unless your UML tool is going to spit out its own code, the poor sod who has to try and write code that matches an UML diagram is in for a very tedious job of defining and structuring in this way. Unless it's going to
Re:Not so much (Score:2)
That's not a problem with UML, but with your team: that guy sounds completely unprofessional -- i.e. he agreed to a consensus, and then ignored it, which could happen in any circumstance, not just because UML was there.
UML is useless (Score:5, Insightful)
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.
Re:UML is useless (Score:5, Interesting)
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/ [projtech.com]
Bad mod of parent! (Score:3, Insightful)
It would have been better if the modder had written a motivation why that product (and method) was bad.
Anyone with answers?
Re:UML is useless (Score:2, Insightful)
While most people think of class hierarchy diagrams when they think of UML, but there are a bunch of other (unrelated, really) types of diagrams that are under the UML umbrella as well.
Re:UML is useless (Score:2)
Rarely (Score:5, Interesting)
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.
Re:Rarely (Score:2)
Then, all respect due, your projects are too simple. Flowcharts cannot represent state, communication between objects, threads, or a number of other entirely necessary concepts. A flowchart has trouble representing anything much more complex than a Unix-style command-line application.
Also, if you find that a particular diagram or description style survives requirement changes better than another, it's likely because it wa
Re:Rarely (Score:4, Interesting)
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.
That day has allreay come.
Read about UML/MDA and xtUML. Probably you should just search on sourceforge how many MDA tools exist TODAY.
Not that am I a hughe friend of MDS
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.
So I asume you are still at the university? So you only make toy projects there which are done in 3 monthes and you do them as one person or two peson or three person team?
Of course you then have the fealing you "do extra work".
But no offence, I guess you have not long enough programming experiance? If you had, you had concepts in your mind which are difficult to talk about, but easy to sketch with UML.
Did you ever make a project with 10 people (programmers) and about 5 other stakesholders over a period of 3 years? (Or more people and more years?)
As soon as you have done that you know why you *need* UML.
angel'o'sphere
Re:Rarely (Score:2, Interesting)
Hmm, so all those people who get mad programming skills in high school shouldn't go to college. You know, because you can just walk right into the industry with no college degree because its fucking 1996. Riiight.
Also, I happen to go to RIT where experience is part of the education. We have something called the co-op program where you are required to get 40 weeks of real and paid industry experience before they let you graduate.
Student with ex
UML as a Sketch (Score:2, Interesting)
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
Re:UML as a Sketch (Score:2)
I'd definitely have to strongly second this. I've seen this boil out from working at a few different companies. Those who used UML most strongly also seemed to gain less from it (and one architect seemed amazed and could not even fully grasped the concept that I'd been doing OO design for years without any UML at all... even when m
We try to use UML (Score:2)
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.
For discussion (Score:2, Interesting)
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
Visual Programming Language (Score:3, Interesting)
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?
Re:Visual Programming Language (Score:2)
Re:Visual Programming Language (Score:2)
I think they could be better, and they have gotten better over time. LabView I think is a better example, with the ability to make components and state machines visually.
The human brain is geared more towards processing of visual information than it is textual information. I think to reach our full potential as programmers that's where we need to go.
Also I think having a visual representation of the design which is always up to date because it i
Re:Visual Programming Language (Score:2)
When I say that, what I mean is, assembly would have been much easier than it. Which says enough I think.
Re:Visual Programming Language (Score:2)
There's no reason that VPL should be hard to use, slow or inflexible. There are certainly implementations that are.
It's a young field of study that hasn't got much attention, and I don't think there's any fundamental flaw in the concept, just some fledgling attempts.
Re:Visual Programming Language (Score:2)
Re:Visual Programming Language (Score:2)
UML tools are CASE tools. For that matter, Word and Visio can be considered CASE tools. THe most advanced ones may generate class headers and stub implementation files.
Compilers and interpreters are not usually placed under this umbrella.
VPLs are compilers and interpreters, not CASE tools. The VPL is the programming language itself.
On top of that I never used the term "silver bullet." At best VPLs will make design and maintenance easier, but not by orders of magnitude
Control Problems (Score:2, Interesting)
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 DS
UML Fever (Score:5, Interesting)
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.
Use Cases (Score:3, Interesting)
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.
dumb question (Score:2, Interesting)
anyway.. where is the speech to code to useable apps dealie? heh, that'
Re:dumb question (Score:2)
The code tells you everything you need to know AND has the virtue of actually being what the computer will do. Comments are there for the tricky sections and to give a high level overview of what is happening or the "why" of what is happening, rather than the "how".
The problem that you typically have when reading code isn't figuring out what each line is doing, but building up the mental overview of how all the
Was the original point completely missed? (Score:5, Insightful)
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 [objectsbydesign.com] 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 [hillside.net] and the GoF book [amazon.com]. 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.
ER diagram overlap? (Score:2, Insightful)
Just a conceptual tool, not a silver bullet (Score:4, Insightful)
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.
Any Good UML Experiences? (Score:3, Interesting)
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?"
Re:Any Good UML Experiences? (Score:2)
with soap (not SOAP) (Score:2)
Don't confuse the issues (Score:4, Insightful)
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)
Re:Don't confuse the issues (Score:2)
Just to offer clarification, "the three amigos" reference is to Grady Booch, James Rumbaugh, and Ivar Jacobson [wikipedia.org].
Re:Don't confuse the issues (Score:2)
The way my teachers tell me to (Score:2)
I generally don't use it (Score:2)
A test for whether UML is right for you (Score:5, Insightful)
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.
ALL UML, or just the models? (Score:2)
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
Generate UML from code _runs_ and vice-versa? (Score:2)
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.
Just need some boxes and arrows (Score:2)
Maybe it's useful to autogenerate IDL or someting, but I've always found that to be a completely broken concept entirely.
Reed
automation is the killer part ... (Score:2)
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)
Tools (Score:2)
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 diagramm
UML Is a throwback to When Cost Was No Issue (Score:2, Interesting)
Diagnosing and Recovering from UML Fever (Score:3, Interesting)
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 use it to understand other people's code (nt) (Score:2)
Use UML like this (Score:3, Insightful)
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
Requirements Requirements Requirements (Score:3, Insightful)
Re:UML = OO Kool Aid (Score:3, Interesting)
Think about that next time some guy from marketing drops by to ask for a new feature.
Re:UML != Language (Score:2)
Actually, you're wrong there. It's a floorwax AND a dessert topping.
As Martin Fowler [martinfowler.com] states in UML Distilled [martinfowler.com]:
UML can be a programming language in and of itself, where all the code for some application is UML, or it can also be merely used for var
Re:UML != Language (Score:2)
Re:UML resources (Score:2)
(I think it's referenced on the UML website, but I'm not sure - I haven't visited it in a while).