The cost of building DSL / DSM tools

Most of the costs of developing software are attributed to the maintenance phase (often I hear 80%).

I never heard anyone disagree with that.

It makes sense to get your design right from the start - as mistakes in the design phase are normally the most costly ones to solve later on - a good initial design, though, does not eliminate or necessarily reduce the amount of cost that goes into the maintenance phase.

Often I hear the question on how software development with DSL's relates to this wisdom. It's a good question with a simple answer, but there is a better question.

The simple answer first: DSM languages (or: DSL's) aim at development on a more abstract level. The maintenance work, therefore, is also done on a higher abstract level, making performing this work more effective and thus less costly: a change in requirements is much easier to implement. When it comes to getting the initial design right, DSM languages provide better support than general purpose modeling or programming languages: The "wisdom" of the expert and rules imposed by the underlying architecture are (or should be) encapsulated in the modeling language and prevent silly designs. This does not mean that the developer can be a brainless chimp, in fact the more knowledgeable he/she is about the problem domain the better (just like when not using DSL's), but the support he/she gets from the language in getting the design right simply is more prominent.

The better question, however, focuses on the tools for implementing DSM languages and generators (or MDD if you will):

How does the issue of maintenance and "getting the design right" relate to DSL tools?

Why should building your own model-based code generation tool (or tool-chain) be any different when it comes to the design and maintenance issue? Isn't it likely that 80% of the cost of building your DSL tool (or MDD tool chain) will come down to maintaining it? I dare say that the 80% is a rather mild estimate.

Sure, you can get an MDA tool, based on the industry-standard UML language. You will draw complicated pictures, outdated immediately, you won't generate anything useful and you will have very little tool maintenance. You can claim you do MDD but you never even have the time do it or to evaluate the true MDD alternative because you're so darn busy all the time maintaining your code. For you, reverse engineering must be a blessing...

With DSL/DSM tools you shift (most of) the maintenance effort to the language (and generators) you are using. Just like your code in software development today, now your modeling language(s) and generator(s) will need maintenance: You will not get them right immediately and even if after a while you get them right you will still need to change them later on.

So, are we no step further with DSM? Do we just shift the maintenance work to another, more abstract level? No, with DSM less developers will do the maintenance work, preferably the smarter ones and their work helps the less-smarter ones (who are still smart, just a bit less) do smarter things faster.

When using DSM/DSL technology correctly, the major chunk of your work over time will be focused on updating your modeling languages and generators. In my opinion it makes sense to choose a DSL/DSM technology that supports this fact: You do not want the majority of your developers to wait for a couple of days/weeks until the expert provides them with a new, thoroughly tested version of the modeling language, do you? And what about having your developers manually update all models made with the previous version of your modeling language when a new version comes around? That's a lot of maintenance work man. You can claim you're doing DSM or DSL or even that you have a Software Factory, but the factory sucks, and you probably do not have the time to claim it.

Microsoft have a pretty good solution to this problem with their DSL tools: A factory for making factories. I do hope they improve it though as I hear it does have some significant drawbacks. It's been ridiculed but they did think a lot further than the people doing the Eclipse GMF/GEF. The latter have not even started thinking about the maintenance problem, making the framework ideal for code-savvy pet-techies who just like to build stuff and care less about doing (or staying in) business.

The risk involved with DSM/DSL technology can be reduced in several areas:

• Making sure you build a good language and generator
• Adopting a supporting technology that is forgiving to the mistakes that you WILL make
• Tool and consulting support by an organization who have experience in this area
• Assigning tool-evaluating techie who understands that technology is there to support business, not for technology's sake
• Understanding the social and organizational changes that DSM/DSL technology will introduce in your organization and getting support for it
  

Vendors and tool comparisons

I've been pretty amazed (yep...understatement) of how some vendor-executed (fabricated is probably a better description) tool comparisons happed to end-up in tool evaluation reports, which in turn amazed me that these things ended up there, copy/pasted in the first place.

Food for thought: Vendor-executed tool comparisons are always subjective

Don't use a vendor provided tool comparison in your evaluation report. The fact that the vendor-executed tool comparison shows that vendor's tool scoring best in most (some vendors take it that far to score best in all...ghehe) categories, should ring a bell: Something fishy is probably going on.

It's easy to twist a tool comparison in your own advantage:
a) you lie (it's called marketing)
b) you base the competition's data on some old, no longer supported product version that no one really remembers
c) you take only those categories (and give them complicated names) that you score good in, and lie about the competition

It's not the vendors fault really. It is ,however, embarassing to see a tool comparison literally copy/pasted from a white paper or website end up in a tool evaluation report. Sure it saves time making the report, but the potential for losing a year or two in extra work due to your wrong choice or laziness in making the report is very much there.

In a bid to help domain-specific modeling tool evaluators, we added a MetaEdit+ feature list to our website. We did not feel our opinion about a competing tool should matter to you, hence we left the column "other tool" empty, for you fill out. Also did we not feel qualified to categorize our tool features as "best", "average" etc. so we just kept it to "supported" or not. Should you feel we missed some categories then we will be glad to add them there.

More on templates

It was nice to see Microsofts' Gareth J agree with me when it comes to providing DSL tool users with ready language templates, i.e. generally a bad idea. It just leaves me to wonder about Microsofts' DSL tool strategy to provide users with complete ready languages (not leaving it just to templates but go the whole nine yards in providing organization A a method that organization B says is probably best for them, without knowing a whole lot about how exactly software is developed in organization B). At least, this is what the media tells me to be the strategy Redmond will follow and of course the media does not always get it right, but this most often happens when editors think they understand a new technology (...but then they don't...and still write a story on it), my guess is that they often get it right on strategy. Especially when interviewing and quoting team members and project leaders.

I wrote my earlier post on language templates with in mind the idea we at MetaCase have that it is probably best to allow the organization that uses the DSL to define that DSL... themselves and make defining tool support for the DSL (in the end that is what we need) convenient.
There are several reasons for this conclusion:

1. MetaCase employees only know a lot about Domain-Specific Modeling tools, we do not pretend to know how software is or should be developed in different vertical problem domains
2. Providing a ready-language to many (say more than 2) ALWAYS leans toward the one-size-fits-all problem that we see with UML: users want to change it to become more domain-specific, which if you would, often suffers from its original version legacy: The template problem.
3. Allowing users to define their own, makes them think more and in different ways about their problem domain, which has the effect that they will start to understand their problem domain better, which is undeniably a big advantage, which can lead to more concrete advantages

Of course there may be the argument that MS focuses on horizontal domains instead of the presumably vertical domains that we at MetaCase focus on but even then I feel that many of my arguments still stand: It is better to allow companies to define their own DSL and code generators, this is what makes them really domain-specific, which provides the biggest benefits.

Webinar: Domain-Specific Modeling

Domain-Specific Modeling promises to change software development in many companies by changing models from being a bunch of out-of-date rectangles, diamonds and lines to executable representations of solutions in domain-terms. Models no longer depict the soon-to-be-roundtripped, visual representation of the code you need to write later. Instead, the implementation is generated automatically and completely from your high-level models, similar to how compilers generate full assembler from current programming languages.

A free webinar by a true expert in this field on December 14 will give a very concise explanation of domain-specific modeling in an easy to swallow format. So sit back, relax and learn. Learn what?

2 things basically, what it is and whether it makes sense to look into it further. Register here.

Released: MetaEdit+ 4.5

Defining modeling languages graphically in the new MetaEdit+

Today we are releasing the latest version of MetaEdit+. Version 4.5 is stuffed with a lot of significant improvements compared to its predecessor, like to name a few of these:

• Graphical metamodeling (see above)
  
• A whole new generator definition system, that:
• instantly validates generator scripts
• provides a debugger for defined generators
• provides "live code": generated code links back to its original model objects for tracing
• allows you to build more powerful, better generators, faster
  
• Model, and metamodel import/export via XML
• An improved SOAP/WebServices-based API that provides access to models, metamodels and MetaEdit+ functionality
• More powerful metamodeling capabilities
• Symbol import in SVG & Bitmap formats
• A much improved modeling environment

To sum it all up, we clearly focused on allowing developers to obtain tool support for domain-specific languages faster and more conveniently. As an indication: Just for fun, yesterday I "equipped" MetaEdit+ from scratch with Use Case modeling in about 15 minutes. Try that with the visual studio DSL tools or the GMF framework from Eclipse and you'll grow a beard...a big one.

Additionally, our development team put in a big effort in opening MetaEdit+ up, allowing it to work via open-standard SOAP-Web Services, via ANY programming language with ANY tool.

To top it off, we now offer companies, their first license of the new MetaEdit+ Workbench (introductory license) at 150 Euro! Additional licenses carry our normal pricing. There is thus no reason to miss out on experiencing how much value, speed and convenience MetaEdit+ offers.

Free training on creating DSM languages

At the coming OOP 2007 conference in lively Munich, expo and conference attendees have free access to all vendor tracks. MetaCase will provide one that teaches participants "hands-on" how to build a domain-specific modeling language and how to obtain tool support for it. Our aim is to provide participants with something a bit more valuable: Leaving the class room after 90 minutes feeling you've really learned some skills, instead of being made aware of a bunch of product features.

People should bring their own machine, and may opt to bring their own DSM tool. For those that wish to use MetaEdit+ we'll provide them with a copy. From a skills perspective, it's irrelevant what DSM tool you use really. Whether its Eclipse GMF, DOME, GME, Microsoft Visual Studio DSL's, MetaEdit+ or any other tool that can support DSM languages, they're all welcome to the session!

MetaCase offers a free ticket, you can get it here. It also provides entrance to all keynotes, product sessions, special training, vendor tracks and the expo.

New Event: Code Generation 2007

Mark Dalgarno, editor of codegeneration.net pointed me to a new conference, Code Generation 2007 on, well, code generation that his company is organizing in May 2007 in Cambridge UK.
The conference is currently seeking people and companies that are interested in running a session and/or sponsoring the event.

With very few (to my knowledge at least) events on code generation in the UK, this seems like an excellent opportunity for many companies to get exposure.

OMG: "MDA and DSL are the same!"

I came across a webcast by OMG Chairman and CEO Richard Soley in which he claims that MDA and DSL is "the same thing really", since MDA provides DSL's as well via MOF and UML profiles. I agree with Richard that you can get a DSL via MOF and UML Profiles, except that this way we'd have to bin that "little issue" of making sure we get a quality DSL (or DSM language, a term I rather use).

So, what defines the quality of a DSM language? Of course that is debatable but I would suggest "Its ability to define an application correctly, conveniently, concise and completely, with a minimum amount of effort." as that provides the basis for being able to generate 100% of the application's implementation in code. In this light, the lack of quality provided by MOF and UML Profiles leads to incomplete code generation. Richard mentions 70% code generation "which is not bad". Well, it's not good either since it creates the need for keeping models and code synchronized via round-trip engineering, which makes it pretty bad in my book.

When it comes to convenience, Richard "rubishes" the concern so many developers have with UML being too complex, by saying that he - as a man - "likes to have a big tool box", because he "wants to use a tool that is best suited to the problem at hand." To me it seems that Richard's big tool box contains just one very big and complex tool that you can use for whatever it is you wish to develop, therefore not making it very well suited for any specific problem at hand. It's "OK, nothing more", which already may be overstated. Don't give me that crap about it being great for everything.

Providing a developer or company with a great tool for modeling and generating the software he/it wants to build, means providing the ability to conveniently build an own tool that precisely matches the domain-specific requirements, in the shortest time possible. Not by providing a one-size-fits-all big man's box of tools that are "pretty OK" for doing almost anything.

MDA and DSM (using DSL's for generating code) are NOT the same. The OMG would do good to stick to its own MDA vision, abandon it or make an attempt to define it more concisely, instead of positioning it as the greatest thing for all of mankind while trying to jump multiple bandwagons and please everyone's agenda in order to justify its own existense.

Rants, Strikes, Planes and Wheels

It seems OOPSLA has its way in causing many to rant about reinventing wheels, not buying the latest book, airlines, stupid business decisions, blatant tool marketing and what have you. I suppose it's the "lovely" autumn weather and returning darkness that triggers our emotional outbursts.

The good side of it all: the DSM Workshop (6th time) at OOPSLA keeps on growing in size, a clear indicator that we're making progress in our market creation activities. Also the media are now clearly picking-up on the issue on a larger scale, so are the analysts..... so are businesses, and good for it!

With the new MetaEdit+ on its way to being officially released soon, MetaCase is making it significantly easier and definitely more convenient for businesses of any size to start developing software more effectively (faster, less complex, better quality, less cost, less testing, less development time) than with all-purpose UML.

Despite the ugly weather and everybody's rants, I am delighted to see this happening.

MDD & Product Lines Conference review

Markus Völter, one of Germany's most respected consultants in the area of software engineering and software technology, also founder of Software Engineering Radio posted some comments about the recently held Model-Driven Development and Product Lines Conference in Leipzig, that I blogged about earlier.

He comments about using MetaEdit+ being a great tool for building modeling languages and his wish to use MetaEdit+ as a front-end to Open Architecture Ware (oAW) generators. This is something that one of our contacts is actually working on right now, his comments were that "currently the process of assembling a working and useful editor with GMF is quite painful and time consuming. It's just not feasible for larger models." and that “Modeling with MetaEdit+ was indeed quite convenient and a lot easier to accomplish than trying to achieve the same results with Eclipse GMF.”

MetaEdit+ already provides the ability to plug oAW into it, via the model and meta-model import/export facility in XML format, which oAW accepts. Alternatively, there is also the SOAP/Web Services-based API that MetaEdit+ provides. There should thus be nothing stopping Markus from using MetaEdit+ more intensively :)

DSM @ DevWeek 2007 in the UK

Juha-Pekka has been invited to speak about defining domain-specific modeling languages and generators at DevWeek 2007, the UK's biggest conference for developers. On Thursday, March 1, JP will "demystify DSM, open the lid on OMG's MDA and shine a light on Microsoft's Software Factories".

Besides showing why UML-based MDA is generally a bad idea (do notice that not a single session in the whole conference deals with UML-based MDA anymore....hmmm maybe JP should just leave the lid where it is and focus on stuff that works), he will discuss the steps developers can take toward defining their own modeling languages - those that suit the work to be done better and therefore making them more effective - and generators, making sure that whatever it is the generator spits out, is what they want it to spit out.

From a guy with over 15 years of experience in this field, you can expect the session to be enlightning, well worth a visit.

The problem with language templates

When the idea behind DSM and MetaEdit+ has just settled in the minds of many people I talk to - these usually include developers, their bosses, magazine editors and analysts - I regularly get the question about language and generator templates: "Do you offer any ready-made templates?"

Although this would seemingly make adopting DSM faster by offering a "more-ready" solution that users would only need to tweak a little, it actually falls into the "one-size fits all" trap that UML offers. Ready-made templates try to do what ready-made templates try to do: offer one solution to many, which is what DSM tries to avoid for productivity reasons. A solution that needs to work for many, even if they are all active in the same horizontal or vertical, has to make compromises in the design of the modeling language and therefore the code generators, which negatively affects the productivity boost that DSM seeks to offer.

What we at MetaCase see, is that there are huge differences between problem domains, even between companies in the same vertical that make the same product. They benefit from DSM just because they can design the modeling language to fit exactly the way they wish to design their products/systems: Not surprisingly, the desing languages they use differ completely from one another in terms of the concepts they use, the rules that apply to them....the abstraction level they work on.
Providing them with a ready-made language template would:

• Get them started on the wrong path: They would not think carefully about their problem domain and attempt to create a language that would fit it. Instead, they would take the ready-template and try to fit it to their problem domain via all kinds of complex adaptations (similar to the UML profiles approach): Let's do it quick and ugly.
• Because of this, limit the possibilities and flexibility to generate the code they need, leading to a need to reverse engineer and round-trip: A road to nowhere...

The problem with language templates is that they exclude the much better solutions that exist for an individual problem domain. Although the idea seems a good one at first thought, once the idea of DSM matures however, providing or using ready-made templates seems a lot less attractive.

DSL: How to start creating your own language

This is becoming a more important issue for many, since modeling with DSL's or DSM languages is clearly picking up steam. Some stuff has been written about it but I feel it's definitely something that deserves more focus since it is such an important aspect of DSM. Sure, many experts, evangelists and even MDA-guru's speak about meta-models and, if you're living life on the OMG matrass, the good and bad of MOF. This is mostly the "WHY". I've seen only few give advise on the "HOW".

It seems that once you get into a serious session of DSM language creation, the tendency is to push it as far as you can....which often is the wrong thing to do: You're re-inventing UML.

Some time ago, Juha-Pekka wrote a great article on DSM language definition (for Software Factory aficionado's and Gareth J: This is the more correct acronym for a graphical DSL) and he's got another one coming soon in Methods and Tools.

Business before Pleasure

With Model-based development based on domain-specific modeling languages getting more interest from businesses, I have noticed several times now that teams blindly decide to build their own DSM tool using freely available frameworks, like the one offered by Eclipse, only to realize a few weeks (or months) later that the effort this requires is more than they initially hoped for.

There are many facets involved with building your own MDD tool like providing the ability to define your own modeling languages and generators, defining and associating the visual representation to the defined language, defining tool behavior, providing the means to immediatley test your languages and generators while defining them simultaneously, sharing your languages, generators and models with others, possibly even on hetrogeneous platforms, providing integration with other development tools, supporting different DSM languages at the same time etc. Building your own DSM tool does not end with your first version of it.

It's highly unlikely for one that developers will get their first DSM language right the first time, or that this will be a good DSM language. Furthermore, it is very likely that even a good DSM language will need to change over time, which will have its effects on the models that have been created with it. Normally, defining a DSM mechanism requires developers to concentrate on both language definition and generator definition simultaneously. If those developers also need to concentrate on making sure there is reliable tool support for their continuously changing definitions, the effort becomes very complex, very time consuming and very costly.

In order to make DSM a success, developers need to put the goals of business before the pleasure and challenge of building their own DSM tool from scratch....which is what it comes down to, really, when using free frameworks.

At MetaCase, our vision is that developers should be allowed to focus on building good DSM languages and generators, where the environment helps them in doing so by making the effort convenient and transparent. Developers should not be bothered with the intricacies of creating tool support for their own languages and generators, a good environment automatically provides the tool support for them. Not just for the "using them" part, but also for the "defining them", "sharing them", "maintaining them" and "integrating them" parts.

You don't want to spend man-years in developing a tool that in the end will make you a lot faster just until it inevitably becomes obvious that you need to make a change to the language, generator or tool...........and you can start all over again. This may be nice for people that like to build stuff, just for the fun of building stuff, it completely offsets the benefits the DSM approach has for the business goals.

Thankfully, some people have realized this in time, before having wasted precious time on building from scratch:

“Modeling with MetaEdit+ was indeed quite convenient and a lot easier to accomplish than trying to achieve the same results with Eclipse GMF,”
Ulf Hesselbarth, SIEMENS Communications.

"MetaEdit+ provides convenient tool support for domain (meta-)modeling as well as for the definition of concrete instance data, which is simplified by a domain-specific graphical user interface. Easy to learn — easy to use!"
Cord Giese, Research Analyst, Delta Software Technology.

"MetaEdit+ is the most sophisticated DSM tool,"
Scott Ambler, Ambysoft

"Even as a beginner with MetaEdit+, I could define a domain-specific activity language in about six hours - design, testing and one failed trial included,"
Laurent Safa from Matsushita Electric Works, Ltd., Japan.

"MetaEdit+ was the most flexible tool, allowed us to define our own design syntax quickly, and make fast experiments while developing the method,"
David Narraway from Nokia.

Struggling with Microsoft's wording

GarethJ is wondering if MS's "DSL" tools might make people think MS is targeting textual languages. Remarkable.....especially when knowing that DSL's have for decades been textual languages. It remains a mystery to me why MS have not opted for the more correct "DSM languages", with the "M" representing Modeling. I suppose some marketing buff up in Redmond decided "DSL" to "sound" better and of course......it would save some ink.

UML vs. DSM - The analysts take on it

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.

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.

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.

UML or DSL for Embedded?

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.

SD Wild West Panel

Well, it's been a while but after a long holiday, during the dryest summer of the century here in Finland, I'm back behind my keyboard.

Currently at MetaCase we're working hard toward the release of the new MetaEdit+, which will be awesome. I had some time to go through old emails, stumbled on the panel script of SD West 2006 and my wooden shoe broke (old Dutch saying). In the annoucement to the panel I am sure the SD events group had announced "some heat" that could be expected. However, the script I read does not give any indication of "heat". Instead, it seems like the panelists were given ear plugs and asked to react to issues that were barely related to each other.

The best advice to attendees clearly came from Compuware's John Kern who wanted to point out that it matters who you hire for a software development project. I bet it does John, but don't you think that "Just hire the smart ones and you don't have to worry about getting them there" is simplifying it just a little too much? Comments like that should get you barred from any future panel if you ask me.

Jack Greenfield mentions that he does not believe in big red buttons that generate code he has to live with from high-level models. Well Jack, first, in MetaEdit+ that button is not big and not red, it's actually quite small and blue/whitish and people have been using it for over 13 years to generate full code that they can live with, and yes, from high-level models.

Scott Ambler reacts (according to the script) out of the blue that not everyone gets modeling. Correct Scott. Could it be that this is because UML, the most used modeling language - hyped since its inception by the OMG in every magazine, website and conference - is actually very complex? Would modeling not be simpler if developers can design with the concepts and rules that they are most familiar with - those from their problem domain - while the language makes sure that they follow the architecture and design rules that are valid in their problem domain?

Hopefully the next panel on MDD provides some real fireworks, cause there is enough reason to. A good moderator might help, one who doesn't let panelists get away with half answers or John-Kernisms.

Steven's problem with MDA

Steven has been writing a nice article on code generators on the code generation network. In it he explains his idea of what constitutes a good code generator and some best practices of how to create one. He also elaborates on why he sees that the modeltomodel-MDA (elaborationalist) will be fraught with obstacles and mayhem.

Doug Schmidt on DSM

Software Engineering Radio recently interviewed Doug Schmidt, a professor of computing at Vanderbilt University. The interview became interesting for me from minute 33:30 onwards, where Doug explains DSM, as he also did in his article on Model-Driven Engineering last year.

Doug clearly is an expert in this area and I enjoyed hearing how much his thoughts are similar to the ones I have about Model-Driven Development.

What my experiences with the media and many developers on conferences are, is that further introductions of the idea however, are no longer really necessary. I do not think anyone is anxiously awaiting another book or another article that introduces Domain-Specific Modeling or modeling with DSLs. Instead, we need the minds, expertise and experience of people like the Schmidts, Tolvanens, Kelly's, Dimitrievs, Greenfields, Cooks, Fowlers and so on to focus on:

HOW

Mainly:
How do I best create a DSM language?
How do I make sure I can easily update it later?

But definitely as important are:
How does the DSM tool best support updating the language?
How does it best update and distribute changes?
How does it best integrate generators with metamodels?
How do we best exchange metamodels?

Juha-Pekka has made a significant contribution here in his recent articles on DevX and he will no doubt touch the subjects during his classes on Architecture and Design World. Many of his ideas are naturally part of MetaEdit+ of which the 4.5 version is scheduled for later this year.

"What Scale is worth the effort?"

In his blog "ISerializable", Roy Osherove talks about modeling with domain-specific languages and the ongoing "Software Factories" project in the healthcare sector. Besides the debate on whether the project is a failure or not - (Could it be the type of area Microsoft picked out? My thoughts earlier were that it seems that team Redmond is going far too generic with their Factories) - Roy wonders about "What scale is worth the effort?"

I believe it depends on many factors, such as complexity of the software you are creating, functionality, number and skill of the developers you have, number of possible variants or the amount of reuse of components and libraries you are planning (i.e. in product-platform-based approaches), and therefore it is difficult to answer.

Maybe we should look at the problem of "when does it make sense to apply domain-specific modeling" in the same way as "when does it make sense to apply modeling techniques?".

Currently many developers like it better to write code whenever they can do so, since it is faster than first modeling and then writing code. Complexity of the software forces you to make a model of it prior to coding but in itself thus forces you to solve the same problem on three levels: First in the problem domain, then in the domain of the modeling language and finally in the domain of the programming language. DSM attempts to bring the first two as close together as possible and automate the third step with generators. That way, they have to solve the problem only once. Much faster than writing it in code.

The other reason for modeling may be merely for documentation reasons where, as Roy mentions in his earlier post, models are usually out of date. If models however form the main artefacts of your development effort then both code and documentation will always be up to date as both are generated from the models.

OMG does it again: SysML

Two OMG key committees unanimously approved the ONLY submission it received on a RFP for a systems modeling language. I guess there was a real market need for it....

The submission came from "the usual suspects": Their own member organizations like Telelogic, IBM, Artisan...all UML tool vendors and guess what...SysML is a subset AND and extention to the UML --> a profile!!!

It took the tool-folks little over 2 years to come to an agreement on how to bend the UML in such a way that it supports systems modeling better AND that it still can be supported by their own existing UML tools: drop a few diagrams and add a few.... pretty easy from a tool vendor perspective. No real changes to the metamodel of course. God forbid that these vendors need to make a real change to their tools in order to improve the practice of modeling systems. Why in fact would you? We all know that the standard UML is already good enough for anything!

Besides, with a modeling language that's really close to UML you can be sure the OMG will approve it in record time and make sure the new standard gets appropriately hyped.

Software im Automobil 2006

I participated the annual "Software im Automobil" conference in wonderful Stuttgart last week. Naturally, the issue of autosar had a lot of emphasis in many of the talks. The automotive industry is fighting with complexity issues: Not only is the software getting more and more complex in functionality, it also has to be implemented in an environment that is influenced by many environmental and political issues, that is distributed, needs to be able to be updated, is hardware-expensive, has to run on hardware from different suppliers AND is often developed by different suppliers. The standard, low-level architecture and runtime that autosar envisions will no doubt be a big step toward more control over the spiralling costs involved with software and hardware development in this sector.

Next to autosar, I was surprised to see domain-specific modeling as the next-hottest topic during the conference. A growing number of players in this area start to understand that they cannot build the software or software product lines the build with standard, off-the-shelf development tools and languages like UML or C. UML lacks the preciseness they need and C or similar languages simply are the wrong tool: No one really wants to write 10 million lines of code manually and maintain them on that level. A raise in abstraction, where possible, is a logical next step and this is what DSM provides. In doing so, DSM will provide a proven solution to exactly those issues the automotive sector is struggling with.

MS NS-DSL

Just listened to the ArCAST 7 podcast with Steven, Martin Danner and Jack Greenfield. It sure is worth taking the first 12 minutes or so to listen to, before a bit of a sour Jack Greenfield comes in to start spoiling all the fun with awkward comparisons between monocycles and Ferrari's, axes and scalpels, wine and vinegar (that last one is kind of a meta one, describing the actual podcast). Possibly, the repetative slips in the DSL tool release schedule made Jack a bit edgy...

I do think I get his point though and again it comes down to the focus area of MS, which - all things considered - really is not so domain-specific: Enterprise applications (presumably based purely on dotNet). No wonder Jack does not believe in fully generating applications from models, something that - by the way - is being done already for over 12 years! Key to achieve it is to make the modeling language very domain-specific: I am talking company-specific-product-line-specific-kind-of-specific here: You need to be able to specify products completely and accurately with it. When you realize that some info is repetitive you can either encapsulate that in the generator or the framework code. Now then, if all the needed info is the models, then why Jack, would you not be able to generate the full application from them??

Jack further disagrees with Martin's claim that UML is an OO-specific modeling language (read: DSM focused on OO software development) and coins the term "General Purpose Language" that he suggests in "The Book" (He NEVER misses an opportunity to mention "The Book", you have got to give him that...). Come on Jack, can't you see that the example Martin provides is a rather excellent way for people to get the idea of "Domain-Specific"? Besides, may I suggest that the term you coin in "The Book" is not completely correct? Since we are busy anyway of making sure we do things entirely correct, a better description would be "General Purpose Modeling Language".

Then again, would you call a DSL to describe "web services" - an example I have seen in one of your slides at OOP - a DSL? I'd say it also qualifies as a rather general purpose modeling language or a Not-So-Domain-Specific-Language, a NS-DSL.

My take on the thing is that Jack seems to be missing the point and has recently started to focus on details in comparisons that no one really cares about. Before long people will get tired of hearing exactly how, where, when, why, what for, where not, and from what viewpoint SF differs from MDA and exactly how DSM differs from both SF and MDA, whether we should call DSM languages DSLs or Not-So-DSL or Not So General Purpose or whether we should call MDD MDA or SF or MDSD or DSM....yawn...as Markus Völter said on the recent OOP "Dass ist doch Alles Quatsch" and I fully agree with him.

Point is that we wish to use modeling to raise abstraction, make software development less complex, make it faster, make it more convenient more accurate and more reliable. MDA seems to miss a number of these goals, SF is still shrouded in mystery to many and DSM is clear on this: It achieves them all.

Factory Factory Factory Factory

I noted in GarethJ's weblog that Microsoft uses its own DSL tool for making its own DSL tool. This is an interesting approach as no doubt will it allow them to renew or vary its DSL tool REALLY REALLY fast.

At MetaCase with MetaEdit+, as Steve noted in his interview with Codegeneration.net: "DSM is useful when you are building a range of similar products. We have just the one, so it makes no sense for us in general." I wonder therefore why Microsoft has taken the Factory Factory Factory Factory approach in making its own Factory.

You can only make a Factory Factory if you know enough about the types of Factory the Factory will be ehr...factoring. This makes me think of the direction Redmond is going with their Software Factory: Enterprise Applications, an area I personally do not see all that well suitable for a domain-specific modeling language-based approach (whether you call it Software Factories or DSM), since the variation space is so wide. Hence it is no wonder that Microsoft does not expect their tool will generate 100% of the code. In order to make it work you need to narrow down the domain in some way and this is tricky when it comes to enterprise apps. You could think of a platform like hmmmmmmm .NET or a subdomain of it, but it means at the same time you restrict yourself to just that.

Would the rumor I heard about the Microsoft DSL tool license agreement be true?

MDD in embedded

After many years of resistance it seems that modeling is gaining foothold in the area of embedded software development. I do not have any hard numbers about the acceptance though. Anyone able to provide a pointer here?

Development of embedded software has - like in other areas of software development - grown more complex and the pressure of delivering in ever shorter development cycles has increased. A natural way to deal with complexity is the use of software platforms and modeling.

Although embedded developers have no ears for the OMG's MDA, UML currently is the leading notation for modeling embedded software. The problem with acceptance of UML in embedded has several reasons, one of the most important ones is that UML is an object-oriented notation where much of embedded software development still is functional. UML thus requires developers to adopt another way of thinking about development, which - naturally - is meeting with heavy resistance. Furthermore, UML - as is - is poorly suited for embedded development. While reading about companies like ARTiSAN, I was surprised to see they basically have extended the UML metamodel with embedded-specific (read: domain-specific) concepts: time tags in the sequence diagram in order to add support for timing issues, tweaked UML diagrams in creating a system definition diagram and a system architecture diagram, and finally by adding a whole new diagram with completely new-to-UML-modeling concepts: a concurrency diagram. Nice job as they did haul Siemens VDO in with it, who are using their tool for engine management development.

After reading about it I wondered: Why not take it a step further? UML is missing a lot of notation possibilities to capture embedded software and systems correctly, it still requires developers to think in an OO-way, and even IF they already think in an OO-way then it still does not significantly raise abstraction nor support the design work: What does UML really say about engine management systems, about pacemakers, mobile phones, avionics or weapon systems? Yep....zilch.

If however you define a design language yourself, you have the ability to base it on which ever orientation (OO, functional, look & feel, generated output, hardware architecture, variability, domain concepts) is most suited for your situation. There will be no need to learn a whole new notation as you will use the same concepts (and rules that govern them) that you normally speak about (It will be much more easy to communicate with than with UML) and are familiar with. Additionally, it will not allow you to generate just 80% of the production code but 100%. Forget about reverse engineering....you won't need it anymore.

I will likely write more on this area, embedded development is extremely well suited for DSM.

Definition: MDA tool (2006)

I just read the special on MDA tools in Software Development Magazine. Although it has as title "A special guide to MDA and UML tools", surprisingly some tools in there were neither, nor do their websites claim to be. After reading on, I came to the conclusion that we have to forgive the author for doing this: It seems rather difficult to determine what exactly is an MDA or UML tool these days.

I thought I'd try to give a definition of an MDA tool, based on the information, no doubt carefully prepared and provided by all vendors. Here we go:

MDA Tool: A tool that may, or may not, generate code, limited, or not limited, to just one single technology platform, from models. These models may be the "de-facto" standard UML or some proprietary derivative from this standard (in which case you still seem to be allowed to call it compliant). The model-to-code or model-to-model transformations may, or may not be completely proprietory, and may, or may not be customizable. Some tools already claim to support the "QVT standard" although according to the OMG (the standardizing organization) this is not a standard yet. Some also claim to support the "XMI standard" for model interchange between tools although each tool seems to support its own version of this standard, making model interchange impossible in practice. Also "MDA-compliant" are those tools that support tweaking UML via MOF, proprietary metamodels, standard profiles, non-standard profiles, standard OCL or non-standard OCL ("OCL-like" often is close enough), essentially these are thus standards for de-standardizing the standard OR proprietary means for standard de-standardization, after which you - naturally - may still claim standard-compliance.

Standards somethimes seem to make things difficult, don't they?

Hard Fact: MDA Works!!!

Just de-emphasize the "platform independence" issue, forget about the UML and bin the PSM and any reverse engineering you had in mind.

Industrial experiences of this kind of "MDA" show improvements in productivity and quality with a FACTOR of between 5 and 10 times compared to UML-based MDA implementations.....ehr....hypothetical UML-based implementations of MDA that is :)

Defining DSLs, Best Practices

Juha-Pekka is writing a series of articles on domain-specific modeling for DevX.com. With 15(!) years of experience in this area I suppose he definitely is an authority when it comes to DSLs, more correctly referred to as DSM languages. His second in the series deals with defining DSLs. Over the years involving many workshops, pilot projects and close co-operation with customers he has identified a number of best practices for teams in order to come to good DSM languages, as not every DSL is neccesarily a good one!

Defining DSLs based on RUP

Evgeny Rahman and Jarrod Bellmore from the Worcester Polytechnic Institute have investigated a method for defining DSLs based on the Rational Unified Process. Hats off for their thesis work. While I will not argue the suitability of RUP for defining DSL's (I can imagine a whole future battle between DSL-RUP aficionado's contra Agile DSL guerilla's), I do have much respect for the topic choice they decided on for their thesis work. Defining DSL's certainly will be a key issue. Now that the technology is there and more vendors announcing support for DSM, the next obstacle that those wanting to adopt DSM will be faced with, will be "Ehrrrrrr.....so how do we actually define our own modeling language"?

Next-generation DSM tools may even offer support for various DSL definition processes, including the creation of all documentation for decision making processes during the DSL definition and maintenance. Remember that like developers today, language designers will change jobs in the future and for those that replace them good documentation about the choices made by their predecessors about the DSLs in use and their evolution over time, will help in making future decisions on where to go with the languages in use.

Interview with Steven Kelly

Codegeneration.net has published an excellent interview with MetaCase CTO Steven Kelly about DSM, MDA, Software Factories and developing a meta-CASE, DSL tool like MetaEdit+.

You already speak DSL!

Often a first reaction of prospects - when confronted with domain-specific modeling - is: "So we have to define and learn a whole new language?".

Actually, this is not correct.

I dare say that virtually every developer already speaks DSL! When discussing about the problem domain of the software under development, each development team has their own jargon in which they speak about the software or system. No one speaks about the software in Java, C or, mind you, in Cobol or Assembler. Developers all speak about their software in a language that uses terms and rules from the problem domain he or she works in. Usually, the expert developer speaks that language best and DSM gives him (or her) the means to make each "less fluent" developer "speak" that language fluently.

The idea of course: Give the expert a tool to efficiently create modeling tool support for his/her DSM language and provide this language to the rest of the developers.

Unlike with UML, with DSM developers do not have to learn a new language, that, all things considered, is never really optimal to "discuss" about the software. Instead, with DSM the expert provides them with the language they already know so that "discussing" about the software in your verbal DSL comes closer to developing the software in your visual DSL.

Do you need a sexy DSM tool?

I got some feedback today from someone who had done some hands-on with MetaEdit+, his first comment was that he did not feel too good about the UI, it had a 90ies feel to him. His other comments were very positive though. Although we have seen a major improvement in the UI since the previous version I somehow understood what he meant. I took a look at Microsofts Visual Studio DSL tools tonight to get a feel for how a modeling environment can look when dressed to kill and oh boy..... the guys at MS certainly put in their best cosmetic skills in order to make me wet my pants.

For those interested, MS has an online lab where you can test the new DSL tools without having to install the monster, I hear it's about 900Mb and requires 3 machines ;) , so an online lab comes in handy. Try Googling for MSDN Virtual Labs and you'll likely find it. After some registrations and wrestling between Firefox and a dusty Internet Explorer I got access to the lab, wet my pants, and found my next barrier was my Finnish keyboard setting but luckily managed to solve this fairly soon.

After doing the excercise "Building a Domain-Specific Language Designer" (in English this means: Making a sexy looking DSL tool support a very simple DSL) I have to conclude that I can do the same exercise also with MetaEdit+ within one hour. I admit I do not get the sexy environment with its rounded, shaded toolbars but on the other hand with MetaEdit+ I do not have to import any pre-defined stuff, like ehr...the domain model (read: whole language definition) and its entire visual notation in order to be able to complete the exercise within one hour. A note to the people at the Microsoft DSL team: If you just import all this stuff...can you then still call it "Building a Domain-Specific Language Designer" as the exercise implies?? I think a title like "Opening a DSL project in Visual Studio Team System" would be more appropriate. The sexy environment hardly compensates for the fact that this takes an hour to do.

UML profiles vs. DSL

Some people when they see a DSL for the first time and code being generated from it they respond that they "can do the same with UML and profiles". OK maybe they do not generate all the code but they probably could if they would add action language and use OCL. People often miss the point when seeing a DSL, using concepts from the problem domain it covers directly as modeling concepts. Not only do DSLs use these domain-concepts, the language is also based on the unique rules that are valid in that domain instead of UML's rules that govern object oriented programming in general. The point here, is abstraction.

The level of abstraction on which you specify solutions is directly related to productivity, the higher you can raise it, the more productive you'll become. To those people that keep on hammering that they can do the same thing as a DSL with UML profiles I would ask: Why then is the OMG promoting DSL's based on MOF?

Back from OOP 2006

Just back from OOP in a snowy Munich. Like last year, the quality of the event clearly defines it as the leading European conference on software development in general. Attendance was great, people nice, you could really see people were enjoying it. A lot of big names among the speakers like Markus Völter, Scott Ambler, Juha-Pekka Tolvanen and Krzysztof Czarnecki. I did wonder about the people from Microsoft but I guess Jack Greenfield, Steve Cook and Alan Cameron Wills are too busy with getting version 1.0 of the DSL tools ready for release. Bummer guys, you missed an interesting event and great opportunity to provide some more info about the current state of affairs inside your labs.

It struck me that no one is really questioning the use of DSL's anymore - apart from the usual one guy who misses the point about abstraction and productivity and persistently claims he can do the same with UML + profiles, some manual coding and reverse engineering - and that is a good thing. I believe UML and DSL's are - unfairly - often compared against each other. While there are some cases where doing this makes sense I think the bigger picture should deal with the question of when it makes sense to use the first and when the latter. In the end, both groups of approaches benefit from promotiong modeling in general, something many analysts say still happens far too little.

One morning on my way to the conference I saw a guy from a large German automotive supplier (I saw his email signature in Outlook) switching to his IDE, starting to do some coding. What made me smile was that the majority of his work consisted of copy pasting stuff and making small adjustments. Maybe one day I will again stand in that same train on that same subway line and see the same guy working a lot faster in a DSM environment that not only raises the abstraction level he works on to that of the automotive concepts and rules of his company but that also automates the tedious task of copy pasting the same stuff over and over again.

The other good thing that struck me is that more and more people are aware of MetaEdit+, I guess our efforts in working with many editors of leading magazines are starting to pay off: Looking further into domain-specific modeling fairly quickly leads you to it. Especially companies looking for a graphical modeling front-end to configuring or developing their financial, logistical or what-have-you systems see the benefits of having a modeling language that actually describes their system and that follows the rules that are valid in their unique design area.

I suppose the high of the conference for me was Markus Völters' session on MDSD in which he ousted his opinion on MetaEdit+ being clearly the leading model-driven development tool with the potential of taking the entire market.

Start

Like in real life, it makes sense to keep work and private life separated. Hence this blog that I dedicate to musing and mind-bending about software development, specifically the area of model-driven software development.