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."
True linux-focussed geeks would have immediately wondered why user-mode linux was suddenly such a hot topic, and so dangerous to boot
Simon
Physicists get Hadrons!
This is true, but note that the UML/patterns/OO newbie is in no position to determine that. One common mistake is to read the book, discard the parts you don't think is necessary, and then proceed with your design work. The rules that you chose to ignore were put there by pretty smart people, and there's a good chance they were put there for a good reason. When the design finally fails because you were missing something, the egotistical designer then blames the method.
The point is, I think the parent post was suggesting that the programmers in question may simply have broken the rules, and not actually found some instance where the methods really apply poorly. It's ego-boosting to think that what you do is unique and beyond the reach of old stuffy rules, but the truth is that most of us are doing things that have been done before.
This isn't to say that those cases don't exist, but that they're probably rarer than you think, especially if your team of programmers is trying it out for the first time, especially if you don't have a senior engineer already experienced in the method guiding your team. For the first time, at least, the instructions should be followed to the letter and strictly enforced. They should be dogma until you've at least went through a complete product life cycle with them.
What you suggest we've already tried for decades. The result is prevasively poor documentation and fragile designs.
-- BSD or Bust
Never forget Weinberg's Law:
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization"
Don't blame Durga. I voted for Centauri.
I don't think his point is that projects are too unique to be guided by such rules. He's merely saying that design patterns are often useful, but don't make sacrifices in your own design to adhere to specific pattern rules. It would be foolhardy to think that most problems could be solved by using straight from the text patterns.
Also I think he's driving at another point: you should only model as much as you need to. I think modeling is useful to help everyone understand how the system works but it's not always necessary to model every behavior before you continue with the project.
Pretty widgets? What pretty widgets?
Who uses UML? The designers or the programmers?
/.'ed.
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.
Sorry, this has just been a question I've wanted to know the answer to. And the story has been
- Jax
I found a significant design flaw with a pattern that they were using everywhere and raised it as an issue. Turns out they knew about the flaw but didn't want to fix it since they would have to redo all their UML diagrams for the bulk of the project.
Then they had the nerve to ask me to signoff on the design. Further they had the nerve to ask me to use UML on my next project!
UML is really great for communication of designs. But if you invest too much into the UML you end up "coding" the proposed design and it becomes too hard to modify.
Where UML really shines is in HUGE projects, where systems analysts design the system in UML and programmers write the code. Anything else it's a little bit of overkill and a little dangerous.
UML is nice for modeling most aspects of a piece of software. It shows relationships between objects. UML mostly works best, in my opinion, with larger pieces of software. I think it would be nice to come up with another modeling technique so there would be more selection, but UML itself isn't all that bad.
It would be foolhardy to think that most problems could be solved by using straight from the text patterns.
Um, no. That's exactly the point of them. Maybe not every problem can be solved this way, but yes, most of them can. That's why they were created, but people with enough experience to have seen what works and what doesn't. It's not exciting, and it's not L337, but it's a lot closer to Engineering than some caffiene fueled geek cranking out dodgy Perl scripts at 3am.
Please moderate this thing to obscurity.
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.
Let's not forget that a pattern is a solution to a problem in a context. If the context does not match your situation, then don't use it - even if the problem is the same and the solution is attractive.
UML is what self-important "software architects" are writing while the rest of us are getting work done.
When these overlooked potential pitfalls, start to pust the project dates further and further away, the entire s/w development cycle is compromised and lot of design work is bypassed. Most of the functionality is directly coded from the requirement specs, bypassing all the UML stuff.
And there is the issue of Change management, Over the lifetime of a project , lot of staff changes including developers and designers, and the documentation and UML stuff starts to lag behind the current implementations. There comes a time when the UML diagrams represention is no where near the current functionality of the Code.
Having worked on two very long maintainace projects for very rich clients , I can tell you that initial project delivery is only the tip of the ice burgh. The real deal is maintaining and upgrading the project over a long time, and sadly UML is very inadequate for that.
From a developer's POV , who needs to work on someone else's code ,Nothing and really Nothing is as useful as proper comments in a code.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
UML is a great product for analysing certain types of problems, but early versions are hampered by the lack of decent descriptions of process manangement.
When you talk about UML make sure you know which version you are talking about. e.g., UML 1.3, UML 1.4, UML 2.0.
"Object designs" are well represented.
UML 2.0 is beginning to address this, see articles by Conrad Bock on activity diagrams. So if you are going to use it for any process management make sure you avoid using the older versions.
I find it ironic that the Microsoft adds are using UML as their selling point.
The moral: There are no magic bullets.
One facility I think is particularly absent from UML is modelling of error conditions. In most cases it's awkward to indicate that an error might exist and how to handle it if does occur. Also, UML notation seems incredibly basic (gulp!) and simply can't tackle algorithmic modelling for complex applications like memory management or software interrupt handling in an operating system.
If not already underway, the open source community should step forward and come up with a more advanced alternative to UML and then perhaps demonstrate its usefulness by applying it to a complete modelling of say.. oh.. umm... Linux ;)
Project SDLC specs and procedures require that UML (among other things) be used and relied upon.
I am a contractor, and the first rule of contracting is to do what you are contracted to do:
That is: You are paid to do as you are told, not to do what is right or sensible.
The leading building corporation would proclaim that there's nothing wrong with the buildings and a new market of woodpecker traps and anti woodpecker missiles would thrive.
I've already gotten spams about these products concerning software woodpeckers. In fact, I got one this morning that had a title "SOLVE YOUR SOFT PECKER PROBLEMS"
Don't blame Durga. I voted for Centauri.
HTML Version : here Comments and feedback appreciated.
UML and other design tools are Good Things, and they should be used more often. They really do tend to make things easier in the long run.
However, they do have a major weakness: it's possible to become too reliant on design documents, such that one loses the ability to think on one's feet. It's an easy trap to fall into, but it has to be avoided. Otherwise, any design problem -and such problems are inevitable in any project of significant size- become paralyzing.
The UML Fever article is Slashdotted now, anyway. But, I've seen it before. It's long, bitter, and comes across as a bunch of complaining with no specific information or proposed remedies - other than the implied, "never use UML."
This analogy is flawed.
Programmers are NOT to programs what builders are to buildings.
Programmers are to programs what ARCHITECTS are to buildings.
Builders are to buildings what COMPILERS AND MAKE UTILITIES are to programs.
Now, I suggest that you make an architect work under the same constraints as a programmer:
1) I cannot tell you were the house will be built, so you cannot estimate heating/cooling, snow loads, etc. Can't it figure it out itself?
2) I cannot tell you that the house won't be moved to a completely different climate once built - can't you make it automatically adjust?
3) I cannot tell you what building materials will be available to build the house with. Can't you make your design work just as well with wood as with adobe?
4) I cannot tell you how many rooms will be needed. Can't the house automatically add rooms as needed?
5) I cannot tell you what services, such as electricity, water, and gas, will be available. Can't you make the house work just as well on wind power as grid power?
6) I can tell you that whatever I told you is subject to change without notice.
7) Oh, by the way, now that the house is almost designed - Add a hanger. No, I will NOT tell you whether the hanger is for a Cessna 182 or a 747 - can't you make the hanger figure that out when I park the plane?
8) Oh, the house cannot cost more than US$10,000.
9) Oh, and the house must be build on a quarter-acre lot.
10) Oh, and the house must be ready to move in tomorrow. Morning. Before I go to work.
11) Oh, and the house must be built by two dain-bramaged monkeys with Nerf Tools.
12) Did I mention being earthquake-proof?
13) Oh, the lot is in a floodplain. Can you make it water-tight? Or float? Or both?
14) Hey, how about a houseboat?
www.eFax.com are spammers
I'm sure what I am about to say is covered in part by previous posts but I wanted to try and articulate it a little better. First, before there was UML Object Oriented Analysis (OOA) and Design (OOD) existed. I'm stating the obvious for some but this is often forgot. UML is just a standard language for doing OOA and OOD. UML does not tell you *how* to do the analysis or the design and, in fact, programmers that are perfectly capable of reading and implementing things represented in UML are unable to do the analysis and design needed to build the UML.
So, as a software manager, when I hear an interviewee answer the question "What do you know about UML" and their answer is something like "I have done it using Rational's tools" I want to puke. UML automation tools are nothing more than long rope to hang yourself with when given to a programmer who knows nothing about OOA and OOD.
My advice is to learn OOA and OOD independently from UML and then when you have a full grasp of that to look at how UML might help you in those efforts.
You never saw a fish on the wall with its mouth shut.
Death by UML Fever
From DSP
Vol. 2, No. 1 - March 2004
by Alex E. Bell, The Boeing Company
Self-diagnosis and early treatment are crucial in the fight against UML Fever.
UML
A potentially deadly illness, clinically referred to as UML (Unified Modeling Language) fever, is plaguing many software-engineering efforts today. This fever has many different strains that vary in levels of lethality and contagion. A number of these strains are symptomatically related, however. Rigorous laboratory analysis has revealed that each is unique in origin and makeup. A particularly insidious characteristic of UML fever, common to most of its assorted strains, is the difficulty individuals and organizations have in self-diagnosing the affliction. A consequence is that many cases of the fever go untreated and often evolve into more complex and lethal strains.
Little has been published in medical annals on UML fever because it has only recently emerged as an affliction. The New England Journal of Medicine has been silent on the disease, as has research produced by the world's most prestigious medical institutions. The content of this article represents many years of on-the-job research and characterizes all known strains of UML fever, as well as many of the known relationships recognized to exist between them. The article will conclude with disclosure of the only known antidote for the many and varied strains of UML fever.
Before commencing with the characterization of UML fever and its associated symptoms, it is important to emphasize that UML itself is not the direct cause of any maladies described herein. Instead, UML is largely an innocent victim caught in the midst of poor process, no process, or sheer incompetence of its users. Through no fault of its own, however, UML sometimes does amplify the symptoms of some fevers as the result of the often divine-like aura attached to it. For example, it is not uncommon for people to believe that no matter what task they may be engaged in, mere usage of UML somehow legitimizes their efforts or guarantees the value of the artifacts produced.
This article exploits the fact that the presence and associated severity of many software-related maladies on a program can often be observed and measured in terms of UML: too much, too detailed, and too functional, for example. Some readers may be quick to suggest that the same exploitation could be made regardless of a program's selected modeling approach. There may be some truth here, but no other technology has so quickly and deeply permeated the software-engineering life cycle quite like UML.
The Metafevers
Extensive research has shown that UML fever can be categorized into four well-defined groups, known as metafevers. Their common laboratory names are delusional, emotional, Pollyanna (a person regarded as being foolishly or blindly optimistic), and procedural (see figure 1). Each of these metafevers is described in the following sections, as are the strains associated with them. Although much more is known about each of the strains than written, the objective of this particular article is to describe them to the extent that they are characterized and distinguishable from the others.
Delusional Metafever.The delusional metafever comprises UML fever strains that are considered by many to be among the most deadly. This metafever is best known by its devastating effects on the thought and judgment processes of otherwise healthy managers and engineers. It is very common for the fevers in the delusional category to damage the human immune system to such an extent that the body becomes susceptible to many other UML fever strains (see figure 2).
Utopia fever.Subjects afflicted with utopia fever typically believe that UML is a radical new technology with almost divine origins. Mutterings such as, "How did we get where we are today without UML?" and "Just think how much more advanced our technological revolution would be if we only had UML 20 years ago?" are common amo
OK, that's not really two words, but two words with a colon after it is much funnier than one word with a colon after it. Anyway, folks from the Kansas City area are familiar with Sprint, for whom we've all worked occassionally. It's your typical environment where management is non-technical but deluded to the contrary and they overcommit to things like RUP, UML, and code generation toold. Some people will tell you there should be sequence diagrams for every single bit of logic in an application and so on. It's all been said before and I'm sure there are many Sprint's out there. The applications work eventually, but at great cost, delay and frustration.
In my rarely humble opinion, UML is misused as just another management crutch, like powerpoint and outsourcing. Managers want to wow their uppers with charts and graphs and a few simple innovative ideas rather than than be hands on and make the tough decisions required to bring a project in on time and on budget. They put all their faith in an ideas like UML and RUP that they themselves don't fully comprehend and expect the world to magically change.
I was recently in a working group meeting for an insurance standards body called Acord. Somebody whipped out an interaction diagram and all these MBA's thought it was the second coming of Christ(or the first coming if you're Jewish).
The way I read that quote, the idea is not to pick and choose the rules you like, but rather to throw out the whole thing if it is not working for you. If pounding nails in with the butt of a screwdriver is not getting the job done right, don't put a different handle on the screwdriver; get a hammer.
I see here a reaction to something I'd noted myself: for a number of developers, OO ceases to be a tool in the toolbag and becomes their religion -- they want to evangelize all of the unconverted, and strive to see every aspect of life through the OO lens. The book I'm reading right now contains some side-splitting examples of using the OO sledgehammer to crack a programming peanut, and I'm sorry to say that in my experience this practice is not confined to tutorial material.
There's a step that comes before "what's the best way to code this?" It's "what's the best way to *design* this?"
What is the justification for the 'L' in 'UML'. I realize that in the loosest sense, UML is intended to be a means of communicating ideas, but it feels extremely primitive, like cave drawings. There's not even a standard machine-parseable representation for UML so that various programs can generate/manipulate/transform UML models without reverse-engineering some proprietary cryptic file format. And as for communicating person-to-person, I find it much more practical to use design-pattern language and a few terms from The Jargon File to improve communication with my team. Think about the jargon used between surgeons and their assistants -- to me, that's the kind of language that actually improves communication where it matters...UML seem to take the part of the development cycle that proceeds at the most frustratingly glacial pace and make it even slower. And that seems to make it different from all of the other languages that I've learned.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
UML is the devil.
hear hear!
> You see, 20,000 years ago, our clever, but
> inexperienced ancestors had to make new shelter
> every few days/months/years/whatever, simply
> because they made them from mud.
Buildings made of mud (in adobe brick or rammed earth construction, as it is called these days) are much sturdier than the frame matchbox you are living in. In fact, rammed earth walls are so durable that some of them are still standing after 5000 years of rain/wind/hail etc. And they are more energy efficient too.
How many people use ad-hoc diagrams? Most of the best diagrams I've seen don't follow any standard but do a better job of documenting.
Deployment diagrams are the best example I can think of as they are the most common to not be done in the UML yet they are always easy to understand. (I never could figure out how to describe clustered/redundant/distributed environments with the UML)
I think class and sequence diags are the only ones worth standardizing and I actually like them. Maybe it's coincidence that these are the ones the 'analysts' don't understand.
The only point in standardizing the other diagrams is so that they could be loaded in to any modelling app. Most UML apps don't even agree on what is/isn't UML anyway so why have them?
I agree UML is fine for HUGE projects as long as HUGE is defined as 'just a little HUGER than the one we are working on'.
Eat at Joe's.
I think the moral is, that people who fart around all day determining which programming methodology to use are unlikely to be able to actually deliver a completed project. They are what is called 'poser retards using big words to look cool enough to continue recieving a large paycheck'. In life, the bigger the paycheck, the more of these buffoons are attracted like flies to it, and the more likely that the dollars will in fact go to feeding these parasitic maggots.
Eat at Joe's.
Back then, it wasn't UML, but "Data Flow" diagrams that were all the rage. We all took this "Yourdan" course and learned how to draw data flow.
What happened in practice was Management (including me ;-) drew these pretty little spider diagrams that were in a big thick book that pleased the Navy, and the programmers would write the actual working code that had little relation to the Yourdan diagrams.
My brief experience consulting with IT groups today that use UML reveals the same patterns. Some people earnestly draw UML in the beginning, and tools automatically make UML diagrams based on the code, but other than for top-level interfaces, nobody cares too much about them. It's a checkbox item.
(I'm glad I'm not an IT guy working in a UML sweatshop!)
Best Buy can have you arrested
was that it was supposed to be heavily utilized by CASE tools. And the OMG never sat down and wrote a standard serialization format for it? That was an enormous blunder.
Currently your best bet is to store them in Rational file formats and hope everyone else has Rational.
Criminal.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Rammed earth walls will survive much stronger earthquakes than frame construction because they are much thicker and heavier (meaning that they will have lower natural frequencies unlike wooden frames, which can resonate with the earthquake and rip themselves apart), but also more flexible. Being partially buried is also a great help in damping vibrations.
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
Hi! Has anyone of you ever used a rule engine system in combination with a design tool? I've considered this route for quite a while and still wonder how much commercial potential there is...
available for non-commercial/personal use?
There's always BON diagrams...
Let me start with two obvious points: sometimes people abuse even the best technologies; UML is not the best technology anyone ever invented.
I am confident about this second point for two reasons. Firstly because off and on I have been involved in the UML standardization process [I still attend some of the meetings, although more out of vague interest than active participation since the group I was part of long ago rolled over when several large companies jumped up and down on us] and because it's a view shared by most people involved in that effort. Secondly because I am very active in the modelling community, and some of us have much better technologies than UML available to us. And we can do some very cool things now, trust me - some of this stuff is being used in places that continue to surprise me when I learn of them. Whilst the technology is still developing, it is already classed as industrial strength (although small industrial would probably be accurate at the current time).
Modelling is a Good Thing when used in the right situations. Modelling and UML should not be seen as being synonymous with each other. Modelling doesn't even need diagrams, and it is about far more than class diagrams even if those are involved.
I predict that over the next few years UML will decrease in importance as modelling as a more general concept increases. Of course, UML will still be important, if for no other reason than everyone owns UML books, but different modelling languages will be used when they are appropriate. All hail the new future.
Having used Rational Rose, I cannot imagine that people actually pay money for this crap.
Booch should have killed himself long ago.
Rose is an expenisve, underpowered, undertooled, poorly documented, tool with an incredibly crappy ui and a million bugs.
Rose is the perfect anti-pattern to UML.
Insert image of a spinning Homermobile & Homer with arms stretched out in 'tada' form.
I think it's really close with the exception of #8!
IMHO, s/use/rely on/
I take your point, but there's nothing to say that you haven't just found a new context in which an existing pattern can usefully be applied. (After all, by definition something is a pattern in the first place only if it's got multiple real world applications.)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
UML Gone Wrong
Maybe we need to ask ourselves why things go out of sync in our profession so easily? Our docs. get out of sync. Our code gets out of sync. Even programmers get out of sync. Maybe that Slashdot story on Collaborative tools is more important than we think?
Solve that and we'll be that much closer to being an engineering discipline, instead of a hodge podge trapped under one roof.
That sounds suspiciously like the waterfall model.
And that sounds suspiciously like the big problem with the waterfall model...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I'll save the typing and just link:
DbDebunk.com
Thanks,
--
Matt
...and when the method fails the snake-oil salesmen blame the implementation of that method. UML bigots are exactly like Extreme Programming bigots; they believe the tool is a panacea, so any failure when using it must be the result of not using it properly. It's a great way to count all the hits and ignore all the misses, and for people who couldn't make a buck by selling drawing programs as drawing programs to make a buck by selling them as something much grander.
Slashdot - News for Herds. Stuff that Splatters.
ArgoUML written in Java. Posidon is a nice add-on. Umbrello is a part of KDE.
What I would like to see instead is an Open Source command line tool uml2code that will generate source code or patches to an existing code base from an XML description. This would not work unless there is a reverse tool code2uml to analyze code changes, with necessary markup of cource, and generate a change to the XML description. There are some work done in the area but no tools that I know of. This aproach would give the benefits of a common XML interface between the GUI and the code generation and also the freedom to work with any normal set of compiler and tools on the output. Hmmm, just dreams though...
Rules (as in business rules and rule engines) are a prime example as to why UML is NOT Universal - rules may or may not be objects, and tend to be defined by or at least verified directly by business types who don't "read" UML. However, say you want to (or more likely, are told to) model business rules in your class diagrams (as the rules will reference data modelled as objects). Well, your options include using OCL, and if your rules are more than constraints, you will need to put rules in annotations, or invent some rule "classes" to hold the rule content...
FWIW OMG is now attempting to address this particular limitation by working on business rule standards that will be UML compliant. There is also a Business Rules plug-in for RUP if you are RUP minded.
Like most things, people tend to confuse UML (a modeling language) with OO methodology and OO best practices. UML does have a role. But its not a substitute for common sense and strong project management!
Lastly, you have to consider who uses UML. System integrators view it as a form of project documentation that justifies additional $/hours. I recall one project doing domain class modeling in Rose, then hand coding the equivalent data classes... (yet another large project with no deliverable after 12-18months, cancelled by a customer who eventually twigged that something was very wrong...).
I have used UML in the past, but it is an overkill for most projects. Here is a quick altenative which works and can be applied mechanically:
1) write all functionality down as text
2) scan the text and:
a) note all nouns
b) note all verbs
3) make the nouns as objects
4) make the verbs as methods
5) write a dictionary.
6) discard what's left.
7) find the common parts between classes (find base classes)
8) draw an inheritance diagram.
9) draw an ownership diagram (the object model).
10) make up some examples and act them out (either by yourself or with a team) to see if anything else is needed.
It has worked for me quite well in the past for most cases. You can also repeat any number of steps any number of times desired, if cyclic developement is required.
Now THAT is insightful. THIS is redundant.
-I like my women like I like my tea: green-
Don't knock mud
yeah... or the entire wall will come down.
Don't blame Durga. I voted for Centauri.
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.
and the only prescription is more cowbell!
(not funny to non-snl fans).
J
Actually, you can be quite surprised how much this can help to visualise the codes, especially when we are doing peer reviews.
For example, we generate sequence diagrams from codes, or unit testing more accurately. And we actually can see easily from the generated diagram that some classes were being instantiated too often (unnecessarily), which we will not discover if we were to see from the codes directly, or until we use some profiling tools.
Also, we make it a point to generate Doxygen reports, which produces and helps to visualise class diagrams hierachy and relationships and the APIs more easily. We don't use JavaDoc since.
These kind of things is possible because of the standardised UML notations.
It is definitely not just a checkbox item.
Hey, that's my password you are typing
I'm wondering how well that would work with code libraries, and pattern matching? Imagine having a program that goes over your UML and finds pieces that match closely with what's already in your library, or someone elses. It's not C&P but it's close. Remember programmers are lazy (work smarter, not harder). Then at that point it will be a process of refinement.
The article contains the famous quote, "Good judgment comes from experience. Experience comes from bad judgment. - Jim Horning."
I've seen this misattributed to several different people. It was originally from Will Rogers.
.plan: file not found
Java is for pedophiles. No serious programmer uses Java.
I thought that he was dead? What would he know about programming?
What book is that?
Thanks.
Bush and Blair ate my sig!
http://citeseer.ist.psu.edu/386839.html
"The Unifed Modeling Language (UML) is claimed to become a standard tool for the conceptual modelling and development of modern Information Systems. In this paper we analyse the concepts of UML and compare them with a rather old industrial development method ISOTEC and the Co-Design approach propagated by the author and others. We show that in many respects UML is far from being new: With respect to syntax it just re-invents many of the old ISOTEC concepts and introduces new names for them... "
Has anybody told Microsoft this?
OMG ROFL BBQ UML!
People can, and will, abuse just about anything.
Many of the "meta-fevers" described in the original article are not unique to UML. They are symptomatic of how people approach adopting many kinds of technology. I could easily make a few substitutions in the article, and poof, I'd have a "Death by XML Fever" article.
Design is good. UML is just a tool that can aid design. There's no "one size fits all" for how UML is used by people or in projects.
The amount of development process required what process is actually necessary, and how the process is implemented and enforced is unique to each organization. UML can be a part of that process, or not. Depends on the people in your organization and what seems to work best.
Care to name the book? I have some coworkers who need the idea that OO does not solve everything pounded into their head.
I still have more fans than freaks. WTF is wrong with you people?
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
Yeah, I guess so. But it won't be a problem for long. I got 76 of these spams this morning, each promising to lengthen my member anywhere from an additional length of 3 inches to an additional length of 8 inches. If I calculate correctly, buying all of them will guarantee a length of more than 20'.
Beat that! (not literally, of course)
Don't blame Durga. I voted for Centauri.
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).
"I want exactly what we have, only better.", Anonymous Twit(tm)
--- TMK
Misunderstanding here. I do not want to model or use business rules. I want to use design rules and make them a bit more flexible in respect of the domain we are currently in. Say, someone models a webapp, he would load a ruleset that reflects some good practice of webapp modeling.
For medium sized projects without dedicated designers I think a feedback system from code to design would be very helpful. It would prevent really bad things to happen when deadline pressure makes people to abandon the main road and going off-road for short term time benefits. I would use XP within the limits for each blackbox and UML to verify conformance.
I never liked the idea to have machine generated code to start with. On the other hand assembler guys had the same doubts about the first compilers. Maybe the uml2code thingie only should generate test transactions for QA verifications. When a verification fails the programmer would have the choice to either fix the code or to update the definitions in the failing UML use case. In such scenario the generated code would only be a test harnesk not the actual code used for production. The interface how to apply the data for all the use cases would of course be written by the programmer but that could be as simple as generating user input and verifying the outcome against the test data, returning true or false.
I would love to get a Unified Test Language expressed in XML as output from the uml2test and let it be input to the test harnesk. Let's scrap the code2uml part too and call it test2uml producing an XML patch for the XML description. Then the designer (mindset) could see what went wrong and weather it is ok to change the design for the failed use case, graphically! I think I might be onto something here! Or maybe just dreams...
are UML evangelists who whine and complain when you don't call it "the UML" (as opposed to plain old "UML"). If you want to really tick them off, call it "Yoo-mel" as in "I just did some Yoo-mel modelling today." or "As you can see from this Yoo-mel swim-lane diagram..." Drives 'em nuts.
Freakin Booch et al. decide there should be a "the" in front of it, inadvertantly inspring thousands of rent-a-nerds to show off how knowledgeable they are by correcting you every time you mention the term in what has become (depsite their annoying efforts) the more common usage.
So, in a manner of speaking, the most durable buildings we have are still made of mud. But really well processed mud.
I've found that my posts don't format quite right w/o a sig.
You and the entire organization you work for are incompetent.
Go learn something new.
When the alarm goes off, dump the fries in the bin, shake salt, and put new fries in the cooker.