Common Misunderstanding of UML
Over at Stack Overflow a question was posted "Is UML practical?". The question itself is fine, but several of the answers were so narrowly focused. I believe that the everyday developer only sees UML as only a common set of shapes drawing a picture. Granted it has a common set of shapes for notation, but UML is first and foremost about modeling. (Big surprise coming from a Modeling Website).
Where did this dis-information come from? In my experience the UML for diagrams message comes from schools/universities and popular UML books. Schools will often only teach UML as a way to diagram the solution you and your team of group participants are going to code up. Well of course it seems a little redundant in that contrived learning environment. UML's concepts are to large to teach in the same class as project management 101 or multi-developer projects 101. Most people just don't go any further with it and thus the collective knowledge is that UML is for making diagrams. A smaller problem in my estimation is that UML books often teach or focus on UML as a diagramming tool. They have to sell books to the PM 101 courses so who can blame them. However, what is slightly more scary is that often in the forward or introduction chapter it will come out that the author really only feels UML is practical for communication ie. drawing diagrams.
Just thought you might need to be reminded that most technical people don't get UML. In 5 years UML will be so mis-understood that it will be viewed like LISP or SCHEME, that thing you used in class that was supposed to be great, but really it was only good for learning how to do X.
Keep an eye on the Stack Overflow post I referenced and the UML topics in general at the website. Maybe we can turn this oil tanker around.
Where did this dis-information come from? In my experience the UML for diagrams message comes from schools/universities and popular UML books. Schools will often only teach UML as a way to diagram the solution you and your team of group participants are going to code up. Well of course it seems a little redundant in that contrived learning environment. UML's concepts are to large to teach in the same class as project management 101 or multi-developer projects 101. Most people just don't go any further with it and thus the collective knowledge is that UML is for making diagrams. A smaller problem in my estimation is that UML books often teach or focus on UML as a diagramming tool. They have to sell books to the PM 101 courses so who can blame them. However, what is slightly more scary is that often in the forward or introduction chapter it will come out that the author really only feels UML is practical for communication ie. drawing diagrams.
Just thought you might need to be reminded that most technical people don't get UML. In 5 years UML will be so mis-understood that it will be viewed like LISP or SCHEME, that thing you used in class that was supposed to be great, but really it was only good for learning how to do X.
Keep an eye on the Stack Overflow post I referenced and the UML topics in general at the website. Maybe we can turn this oil tanker around.
Comments
Of course, even when you do get that set up, many uses of UML are still little more than drawing diagrams that structure the project. The metamodeling and model transformation frameworks that the architects love aren't going to get a lot of traction from software developers who by and large view their UML tool as the slightly clunky Java IDE that their boss told them to use. Nor is it very easy to teach good modeling discipline with something like Java in the picture. In my experience, once a component is introduced with fixed semantics that are not expressed in terms of the modeling framework, the semantic integrity of the rest of the modeling environment is up for grabs. If something has to give, it'll be the modeling tool, because at the end of the day the Java code has to go through the Java compiler.
For better or worse, there aren't a lot of other options than this. Tau G2 has its own action language (derived from the SDL profile), but it hasn't been pushed by the vendor and is in even more danger now that Telelogic has been scooped up by the eight-hundred pound blue gorilla. Instantiations of executable UML, for the most part, require a PhD in UMLology to use, especially since most of them were developed by PhDs. Teaching UML without reference to specific executable semantics is exactly what gives rise to the view of UML as a diagramming tool in the first place (a view which, in my humble opinion, is entirely justified when UML is used outside of a process of iterative refinement that culminates in a model as final artifact of the software system instead of code as a final artifact).
So, in one sense, the parallel to Lisp makes a lot of sense. Very few university-level courses do a good job of explaining what the point of doing metaprogramming in Lisp is, especially since it takes more than a few semesters to for students to reach that level of thinking. So too with UML, which is widely derided by those who haven't acquired the scars of trying to lead hundreds of developers working on complex, multi-component systems with decade-long lifespans. UML just has the further disadvantage that it is almost meaningless except in the context of a particular implementation.
One place I have to agree with you is Executable UML or any similar style solution has a very aggressive learning curve.
To add to your point "widely derided by those who haven't acquired the scars of trying to lead hundreds of developers working on complex..." which makes sense as most professors idea of a large project is 3 student developers and never make anything more than a proof of concept.