Slashdot Mirror
UML Fever
CowboyRobot writes "Queue has a couple of articles about UML:
Death by UML Fever by Boeing software architect Alex Bell
describes the problems that can result from over-reliance on modeling tools, with lighthearted lessons for the software development process in general and numerous illuminating quotations, such as: "Good judgment comes from experience. Experience comes from bad judgment. - Jim Horning."
Then, one of the developers of UML, Grady Booch of IBM, follows with The Fever is Real, in which he explains the motivations for creating the language, how it's used today, and where he expects it to go soon."
Who uses UML? The designers or the programmers?
I should imagine the designers wouldn't be very good at it, and I should imagine that programmers would have better ways to express themselves.
Actually a good designer probably has some experience coding. As to who uses it? Well ideally the designer or project leader should author it and the programmers should be able to read and understand it, so both parties technically use it.
Pretty widgets? What pretty widgets?
Contrary to his opinion, the one he never ceases to state, over and over again, there were modelling systems before he 'invented' them all. There have always been ways to annotate a software design with clarity and there always will be.
Has anyone ever worked with anyone who is totally focussed on the UML? We've had to get rid of them as they don't contribute anything except endless debates and meetings that are way too long. Sometimes you have to deliver stuff. I bet he missed that bit while he was writing papers about how revolutionary he is.
if you've ever worked on a program by simply drawing boxes of components and drawing lines between them, you've engaged in modeling. Or even some simple flowcharting is also modeling. UML is a formalized method to stuff like that (your component diagram would be referred to as a structural model, the flowchart a behavioral model).
Who uses UML? The designers or the programmers?
Almost everyone in a development project. Designers, programmers, testers, etc. Even management and your customer can understand what's going on in most of the models.
As for who would be better, I dont know yet. I'll know better in about a year, as we've started a few UML/RUP projects where I work.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
Actually, UML can also be useful for smaller projects, but used in a different way...
m l). In this mode, all UML does is to allow for a common graphical "language" for expressing your ideas.
. html).
n gLanguage.html).
For smaller projects, you can use UML in a UMLAsSketch mode (http://www.martinfowler.com/bliki/UmlAsSketch.ht
For larger project, you can move on to UMLAsBlueprint (http://www.martinfowler.com/bliki/UmlAsBlueprint
For certain, very specific projects, with very well defined semantics, and very well defined transformations, you can move on to using UMLAsProgramminglanguage (http://www.martinfowler.com/bliki/UmlAsProgrammi
Note that I do not completely agree with where Fowler puts his markers in the continuum of the modes to using UML. I think, for example, that his UMLAsBlueprint is too close to his UMLAsProgramminglanguage. But this may be due to his propensity towards Agile methods.
One thing to keep in mind is that UML is a "language"! It is a means to express a software system. It is _NOT_ a panacea to all software development woes and it does _NOT_ replace good architecture practices! Anyone who thinks the opposite is doomed to failure (and anyone who improvises themselves software architect because they know UML doubly so!).
Things are changing... Look at the Eclipse UML2 project (http://www.eclipse.org/uml2/).
There is an OMG standard for the serialization of UML model: XMI. And there is an OMG guideline on transforming the models: MDA.
Now, if only all tools adhered to the XMI standard as their main storage method... Although most can currently output some variant of XMI (although there's just too many right now).
But then again, this is all about tools. There is nothing that would prevent you from using the UML notation on a whiteboard...
Paul Harmon and I wrote a book on UML about 5 years ago.
At first, I thought that UML was a godsend because it did away with 12+ different modeling languages.
Still, for most of my work, schedules are very tight and my customers usually want to spend as little money on development as possible, so I find myself only using what I consider to be the highest value diagram types: use cases, very general class diagrams, and sequence diagrams.
-Mark
I'll save the typing and just link:
DbDebunk.com
Thanks,
--
Matt
http://uml.sourceforge.net/index.php
Poseidon is a free (beer) tool written in Java. At least, the community edition is free; you have to pay more for advanced features.
Rammed earth walls will survive much stronger earthquakes than frame construction
15,000 recently dead Iranians dispute that claim.
Granted, you can build earthworks that are stable with modern technology, using metal and concrete reinforcements and a better knowledge of materials science.
And one day, software engineers might be able to write a pile of C++ that doesn't fall down when pushed.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
on the Microsoft .NET side of things, there are some handy tools available.
.NET has a command for exporting the entire software project back into UML-- so all your changes are documented! With this capability, you can generate entire UML diagrams for projects that were never documented in the first place.
In my last project, I wrote UML diagrams in Visio (which is really better for flowcharts than UML, but it does the job I guess), then exported the code prototypes... You can generate the code in C# or VB.NET, and it creates all the classes, data members, and function skeletons for you.
Then, after programmers fill in the functionality and make changes, Visual Studio
I haven't used this for many software cycles, plus I am not close to being a UML expert, but I think this functionality resolves a lot of problems with keeping a UML document updated and "alive".
I'd like to see a true OOPs language like Smalltalk (OOPS are strong on prototyping) and UML (Strong on graphical modeling) combined with that tool mentioned awhile back that converts sketches to a refined diagram (Tablet PC's or Electronic Whiteboard). Throw in ad-hoc annotation capability and we are almost there.
Oh, boy. Now we can engage in rabid prototyping and have pretty pictures on the wall, too.
Bring up Smalltalk - or other rapid prototyping systems - and you demonstrate that the methodologies are leading you into the design-religion morass.
Rapid prototyping has been responsible for a plethora of project failures. This is because it consists of attempting to code without a design. That works if one person can keep the whole thing in his head, and breaks when the problem is large enough to need partitioning.
Rule of thumb: If rapid prototyping doesn't complete in 30 days, the project is to big for it. You must fall back on other design methodologies to succeed. Or you can continue for as much as a few years but you will eventually fail.
What you're talking about appears to be hanging automated tools on the rapid prototyping system to automatically infer the design document from the code. (Essentially, you're hanging the skin of a formal design methodology onto rapid prototyping in the hope of patching some of the latter's problems.) This is a cart-before-the-horse approach. But it also backs into the "self-documenting code" and "provable correctness" fallacies.
(It also reminds me - in style if not in substance - of a certain wild-eyed Smalltalk visionary's claim that software testing methodologies would have to improve until they could test his design in less than 30 minutes - because that's how often he changed it. B-) )
The key to robust code is to design it TWICE: Once as a human-readable spec, again as code. One must NEVER be automatically generated from the other - because debugging doesn't find bugs, only disagreements between specified and actual behavior. A particular implimentation of "cat" is VERY buggy if what you wanted was "ls". This is why correctness-proof tools aren't a panacea (and are misnamed): They work from a spec of what is correct, and writing a formal spec is ALSO a programming problem, subject to error.
It's OK for both the doc and the code to be in formal languages. It's OK for there to be a set of tools to perform part of the comparison between them automatically. But if you generate one from the other automatically, the only thing you can test is your generation tools. If it doesn't do what was intended that won't show, because the spec and the code will both prescribe the same "broken" behavior. And it's OK for a human to work from a spec toward code - because he'll be giving critical thought to the spec as he codes, and thus tends to discover spec errors.
But it's important for the two languages to be as different as practical, to put the designer and the programmer (especially if they're the same person) into different mind-sets when writing each. The more different they are, the more likely it is that problems will be discovered during the generation of one or the other. (This is why correctness-proof tools are useful despite being misnamed.)
In a real-world project the code and the design co-evolve to a significant extent. When you find a bug it's usually in the code (because the design went ahead of the code and had much standalone debugging). So you fix the code. But sometimes writing the code exposes a bug in the design. Then you fix the design. When you're done the code and design agree - and they're both near-perfect because the final versions of both withstood the entire trial-by-fire and many-eye inspection.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Well, I'm one of the authors of the UML 2.0 specification, so karma be damned. Here's a totally biased response.
1. UML enables communication on design, architecture that everybody can contribute too. The standard notation and concepts in UML 1.x enabled a foundation for communicating in a team about aspects of software that are not easily gleaned from the code.
I think this in itself makes standardization worth it. Also, it's not a secret language of architects. You read the same books they do.
2. You don't have to have all in one place. The nature of modeling allows models to be developed across different diagrams. UML 1.x is incomplete in this area, UML 2.0 does better. Pushing this notion could lead to some to some interesting places, one could be AOP without requiring AOP code.
3. Some changes are easier in UML. Tools don't do a good job of this, but I find it much easier to change object hierarchies and relationships in UML than in code. Imagine extending this to other areas besides the static layout of classes.
4. Metamodeling. The problem with UML and it's tools right now is the complete lack of metamodel extensibility mechanisms. It's like XML, but you can only use a fixed set of schemas.
This could be a real rat trap, but on the other hand, it could very cool. For example, imagine extending the base class metamodel to add what your project needs for persistence, integrity and object communication, and instead of writing code for every class to enable your special features, you use a model tool and templates to automate most of the process for every class.
5. Little Languages that everybody can use. If metamodel holds promise, it is basis for providing Domain-Specific Modeling Languages that take advantage of common metamodel concepts and visual syntax to reduce the learning and usage curve for every language. Having standards in this area help ensure interoperability and lack of lock in.
Oddly, Microsoft is the only vendor right nowthat really seems to be taking on the notion of metamodeling and DSMLs. I expect IBM and others in Eclipse to do the same around the EMF.
6. Modeling could be a complementary abstraction to programming languages. With some exceptions, we rely on code to produce systems. In some areas, models can often provide additional information that is not "immediately clear" in the code, and can automate the generation of that code.
An excellent example is E/R modeling. I would argue that E/R modeling serves as an good tool for designing relational databases, and shows things about the database that may not be clear from the set of DDL statements.
Now, imagine having the ability to create a whole set of these models that all carry a common infrastructure and tool set. Your DB modeling tools is your XML modeling tool is your OO modeling tool is your Workflow modeling tool, and so on.
The problem is that I view UML as "modeling middleware". I don't see it as just a notation, but I see it as a core infrastructure to base modeling tools on. This probably because I worked on the metamodel. In other words, I've spent too much time inside UML that I see the outside much differently.
Granted, most tools make it seem that UML is pretty (expensive too) pictures. But, hopefully, with UML 2.0, people will understand the real promise of UML and modeling. I think it goes beyond the surface syntax.
Now modeling is not UML. In fact, if Microsoft really pushes forward with Whitehorse, they may create the de-facto modeling standard.
The UML community becomes much more aggresive about providing metamodeling capabilities. Also, XMI needs to improve big time. Also, the OMG and UML would be well served by reaching out to MS and staying in tune with where they are headed, so they don't get caught totally off-guard. There is hope, I think MS has does some good work for the W3C (and some bad work, of course).