It seems Jack Ganssle picked a boiling subject with his "UML Use" article, seen the number of reactions from the embedded world to how suitable UML really is for embedded development. The OMG and several (OMG) tool vendors would like us to believe it's excellent.
I remember an interesting discussion with someone from I-Logix at a conference on automotive software a few years ago. After "getting" the idea behind domain-specific modeling his reaction was that it maybe was 10 times faster than Rational...but "only" 5 times faster than Rhapsody. He never replied to the question if we could quote him on that though.... :)
An interesting reaction to Jacks article: "In my opinion it would not have been possible to do these projects given the code complexity and the safety level (RTCA DO-178B Level A) without a tool like this that both understands controls and can enforce the rules". Essentially, the tool he mentions is a domain-specific model-driven development tool. I haven't heard about that specific one but clearly it differs from MetaEdit+ in that it is aimed at one domain only, while MetaEdit+ can be made to aim at one domain only.
Another comment: "Sure if you give incompetent carpenter a better hammer and saw your not guaranteed a better house. However, if you give a great carpenter the same tools you may just get a house of your dreams". Well....what about giving a great carpenter a set of great tools? Your dream house would be ready when normally you would have just finished the blueprint!
How about this one: " For smaller companies UML's a good booster stage, but it isn't going to get us into orbit. At some point it becomes extra weight and costs more to use, in time and productivity, than dropping it and continuing on unimpeded."
Or some "juicy" ones ;)
"I dont think that anyone here believes that we will ultimately use the UML models as anything more than blueprints for hand-coding"
"The tool stinks. Sorry I-Logix, but for what we paid, I expect better." "important functions that are just too difficult to use and poor support for multiple developers working on the same model. And please don't tell me that these problems can all be solved by purchasing more training!" Put that one in your pocket I-Logix!
"I've been using modeling diagrams for 10 years on embedded 8-bit projects (first Shlaer-Mellor, now UML). I've never used the generated code in a final product and I doubt I will until the tools come up with a better way to specify and debug the models at the algorithm level."
"UML is an extremely powerful anaylsis tool. What it lacks is a graphical langauge that lets you quickly and easilly define code execution at the algorithmic level." Yes, UML was developed for just that: analysis and design, never for code generation, the UML tool vendors came up with that, figured out it didn't work, added a lot of stuff to it to make it stink less and called it an excellent solution.
"I think there could be an interesting connection between LabView and executable UML. They both have the same concept: draw a picture and execute it. Generally LabView works at a lower level and UML at a higher level. If UML adopts a graphical execution language like LabView, then you might truly have an executable model from top to bottom." Well, your vision is a reality, it's called MetaEdit+
"May be the next generation of CASE tools will cross UML and Visual logic programming (like Simulink) + Concurrency in one tool and it would address architects, designers and programmers all." Surprising that also this guy has more or less the same vision: Graphical design that captures behavior. Well add to that the ability to define yourself exactly how code is generated and you have a DSM environment.
It's good to see that modeling is gaining in acceptance in the embedded world, although possibly more by crisis than by liking. It looks like the embedded area is moving toward a situation where, as Geoffrey Moore describes in his book "Crossing the Chasm", it is "bleeding by the neck". I see it very unlikely that UML is going to stop the blood from flowing.
I remember an interesting discussion with someone from I-Logix at a conference on automotive software a few years ago. After "getting" the idea behind domain-specific modeling his reaction was that it maybe was 10 times faster than Rational...but "only" 5 times faster than Rhapsody. He never replied to the question if we could quote him on that though.... :)
An interesting reaction to Jacks article: "In my opinion it would not have been possible to do these projects given the code complexity and the safety level (RTCA DO-178B Level A) without a tool like this that both understands controls and can enforce the rules". Essentially, the tool he mentions is a domain-specific model-driven development tool. I haven't heard about that specific one but clearly it differs from MetaEdit+ in that it is aimed at one domain only, while MetaEdit+ can be made to aim at one domain only.
Another comment: "Sure if you give incompetent carpenter a better hammer and saw your not guaranteed a better house. However, if you give a great carpenter the same tools you may just get a house of your dreams". Well....what about giving a great carpenter a set of great tools? Your dream house would be ready when normally you would have just finished the blueprint!
How about this one: " For smaller companies UML's a good booster stage, but it isn't going to get us into orbit. At some point it becomes extra weight and costs more to use, in time and productivity, than dropping it and continuing on unimpeded."
Or some "juicy" ones ;)
"I dont think that anyone here believes that we will ultimately use the UML models as anything more than blueprints for hand-coding"
"The tool stinks. Sorry I-Logix, but for what we paid, I expect better." "important functions that are just too difficult to use and poor support for multiple developers working on the same model. And please don't tell me that these problems can all be solved by purchasing more training!" Put that one in your pocket I-Logix!
"I've been using modeling diagrams for 10 years on embedded 8-bit projects (first Shlaer-Mellor, now UML). I've never used the generated code in a final product and I doubt I will until the tools come up with a better way to specify and debug the models at the algorithm level."
"UML is an extremely powerful anaylsis tool. What it lacks is a graphical langauge that lets you quickly and easilly define code execution at the algorithmic level." Yes, UML was developed for just that: analysis and design, never for code generation, the UML tool vendors came up with that, figured out it didn't work, added a lot of stuff to it to make it stink less and called it an excellent solution.
"I think there could be an interesting connection between LabView and executable UML. They both have the same concept: draw a picture and execute it. Generally LabView works at a lower level and UML at a higher level. If UML adopts a graphical execution language like LabView, then you might truly have an executable model from top to bottom." Well, your vision is a reality, it's called MetaEdit+
"May be the next generation of CASE tools will cross UML and Visual logic programming (like Simulink) + Concurrency in one tool and it would address architects, designers and programmers all." Surprising that also this guy has more or less the same vision: Graphical design that captures behavior. Well add to that the ability to define yourself exactly how code is generated and you have a DSM environment.
It's good to see that modeling is gaining in acceptance in the embedded world, although possibly more by crisis than by liking. It looks like the embedded area is moving toward a situation where, as Geoffrey Moore describes in his book "Crossing the Chasm", it is "bleeding by the neck". I see it very unlikely that UML is going to stop the blood from flowing.
No comments:
Post a Comment