Nice to see more and more analyst firms agreeing on DSM making MDD work, where UML fails to do so. My guess is that we'll likely see more and more UML tool vendors claiming support for DSM with suddenly-popular buzzwords like "abstraction", "full code generation", "MOF" en "profiles". In the end, MOF en profiles do not raise abstraction, make things more complex than UML already is while vendor-defined generators don't generate company platform-specific implementations.
About Me
Thursday, September 28, 2006
Monday, September 18, 2006
Congratulations to Microsoft DSL Team
Jack, Steve, Gareth, Stuart, George, Jochen, Pedro, Alan, congratulations for the great work in bringing the Microsoft DSL tools this far! Your work means a lot to the category of model-driven development tools based on domain-specific modeling languages.
That the DSL tools have a lot of mindshare is shown for example by the article published yesterday on DevX that introduces the Software Factories approach by Edward Bakker and Christian Weyer. It puts the current (still immature) state of the Microsoft DSL tools in good perspective - don't get me wrong - I really think the DSL team has done an excellent job but there is still a long way to go, just like we at MetaCase had after releasing version 1.0 of MetaEdit+ back in 1993.
One of the problems described in the article deals with keeping generated artifacts and models in synch. It's inherent really to the horizontal focus the DSL's have in Microsofts view, this - in my humble opinion - will often (if not always) lead to an inability to generate full code from models, thus always leading to a chicken-and-egg situation: which one comes first. The article suggests ( I think correctly) that models to get the no.1 spot and proposes round-tripping as a solution. The problem it subsequently does not deal with is the difference in abstraction levels between the two. Steven gave an excellent explanation of this problem in his article on Codegeneration.net. Having to keep stuff in synch with each other always is a recipe for trouble, which is why code generation should aim at being complete.
Still, a big hats off for the DSL tools team at Microsoft, as the article shows, already some very cool things can be done with the current version.
Conference: MDD and Product Lines
The end of the year usually sees a lot of top-quality conferences, like SD Best Practices, OOPSLA, Elektronik and many more. I would like to point also to one, which really gets to the point when it comes to model-driven development. It's got a long name:
Model-Driven Development and Product Lines: Synergies and Experiences
It will be held in Germany, the city of Leipzig on October 19 and 20 and hosts some big names like Markus Völter, Steve Cook (will he demo MS's new DSL tools?) and our own Juha-Pekka Tolvanen (will he demo the all new MetaEdit+ 4.5?)
Furthermore I see that Carsten Bock from Porsche will discuss how making automotive software in fast cars is done even faster with DSM.
With a conference fee of 150 euros for two days of model-driven fun, including food, it's definitely worth the effort.
Model-Driven Development and Product Lines: Synergies and Experiences
It will be held in Germany, the city of Leipzig on October 19 and 20 and hosts some big names like Markus Völter, Steve Cook (will he demo MS's new DSL tools?) and our own Juha-Pekka Tolvanen (will he demo the all new MetaEdit+ 4.5?)
Furthermore I see that Carsten Bock from Porsche will discuss how making automotive software in fast cars is done even faster with DSM.
With a conference fee of 150 euros for two days of model-driven fun, including food, it's definitely worth the effort.
Tuesday, September 05, 2006
UML or DSL for Embedded (Continued)
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.
Subscribe to:
Posts (Atom)