In his article "UML use" on Dr. Dobb's portal, Jack Ganssle wonders how much UML is really used in the embedded arena. Casually he remarks that when visiting the soon to be held Embedded Systems Conference in Boston, you see UML plastered on every expo booth. I am not surprised Jack, especially with a conference program so narrow-minded with 6 classes on just UML and SysML from 3 speakers, 2 of which are OMG members.
In my view, conferences like ESC should provide the platform for demonstrating new ideas and methods – once proven in industry, not for methods and notations (MDA, SysML) that are hyped by tool vendors and standardization organizations who, after modest success in the desktop and IT market now put their hopes on conquering the embedded market with some simple modifications to their standard and tools.
Modeling with UML is happening more in the embedded area, to me that is a sign that clearly the software is becoming more complex, not that embedded developers have - suddenly - started to love or even accept UML. The reactions at the bottom of the article are clear indications of the problem with a one-size-fits all language that a) never was designed for generating code from it and b) never was designed for developing non-object-oriented software or some form of hybrid: The large majority of all embedded development.
One comment describes the UML tool generating object-oriented languages like C++ while actual development is done in C :) as a problem. Actually the perceived problem is not such a problem here: Assuming the UML tool would generate C, you'd still have to throw the code away, trust me.
Another comment claims that non-UML-savvy developers can create diagrams that are "non UML-compliant". Aside from the fact that the "UML tool" here probably is a pen and a paper or some free tool that's the binary version of a pen and a paper, even if the diagrams were "UML compliant" then that really means zilch. UML compliant is not in any way related to quality-compliant, performance-compliant or just.....compliant! UML says nothing about any product, platform, framework or architecture, UML-compliant can actually be a lot worse than non-UML-compliant.
Of course there's the comment about understanding UML being hard. "it seems that engineers understand block diagrams and pretty pictures, with a bit of descriptive text....much better than a full blown UML diagram complete with interaction diagrams". Yes, code visualization (UML) is not exactly reducing complexity, it just presents complexity in another format. UML fails to raise abstraction is why.
And then the nicest, one that sums it all up to me:
"After having used UML based CASE tools for the past 6 years, I must say they are great for prototyping. Other than that, I'll never use them again. Merging changes from multiple developers into one graphical model? It never worked. Code generation? Only the framework and how much time will that save you."
Thank you Jos Dijkstra. UML-based CASE tools simply do not fit embedded development. The problem is not CASE......... the problem is UML.
I hope the highly esteemed program committee of the Embedded Systems Conference - claiming to offer "high-caliber, solutions-oriented technical sessions" and a "a fundamental educational tool offering practical, how-to classes designed to meet the needs of engineers developing embedded systems" - will aim to proivide something in next years' program that actually works.
In my view, conferences like ESC should provide the platform for demonstrating new ideas and methods – once proven in industry, not for methods and notations (MDA, SysML) that are hyped by tool vendors and standardization organizations who, after modest success in the desktop and IT market now put their hopes on conquering the embedded market with some simple modifications to their standard and tools.
Modeling with UML is happening more in the embedded area, to me that is a sign that clearly the software is becoming more complex, not that embedded developers have - suddenly - started to love or even accept UML. The reactions at the bottom of the article are clear indications of the problem with a one-size-fits all language that a) never was designed for generating code from it and b) never was designed for developing non-object-oriented software or some form of hybrid: The large majority of all embedded development.
One comment describes the UML tool generating object-oriented languages like C++ while actual development is done in C :) as a problem. Actually the perceived problem is not such a problem here: Assuming the UML tool would generate C, you'd still have to throw the code away, trust me.
Another comment claims that non-UML-savvy developers can create diagrams that are "non UML-compliant". Aside from the fact that the "UML tool" here probably is a pen and a paper or some free tool that's the binary version of a pen and a paper, even if the diagrams were "UML compliant" then that really means zilch. UML compliant is not in any way related to quality-compliant, performance-compliant or just.....compliant! UML says nothing about any product, platform, framework or architecture, UML-compliant can actually be a lot worse than non-UML-compliant.
Of course there's the comment about understanding UML being hard. "it seems that engineers understand block diagrams and pretty pictures, with a bit of descriptive text....much better than a full blown UML diagram complete with interaction diagrams". Yes, code visualization (UML) is not exactly reducing complexity, it just presents complexity in another format. UML fails to raise abstraction is why.
And then the nicest, one that sums it all up to me:
"After having used UML based CASE tools for the past 6 years, I must say they are great for prototyping. Other than that, I'll never use them again. Merging changes from multiple developers into one graphical model? It never worked. Code generation? Only the framework and how much time will that save you."
Thank you Jos Dijkstra. UML-based CASE tools simply do not fit embedded development. The problem is not CASE......... the problem is UML.
I hope the highly esteemed program committee of the Embedded Systems Conference - claiming to offer "high-caliber, solutions-oriented technical sessions" and a "a fundamental educational tool offering practical, how-to classes designed to meet the needs of engineers developing embedded systems" - will aim to proivide something in next years' program that actually works.
No comments:
Post a Comment