If you have a good tool to rapid create a prototype and simulate your application then UML is pretty good.

Does anyone have tried UML Almighty tool ?

What about the simulated Web application ? Is it good ?

Regards.

“what about agile practices such as TDD, refactoring, etc. What about the inevitable case where the domain starts to evolve (there’s no such thing as non evolving software)?”

Why would MDD be inherently incapable of allowing these? If what I am calling modeling here is just higher-level-of-abstraction programming, what are the challenges with refactoring and automated testing that you are alluding to? They might be obvious to you, but I can’t see any. Models are executable, so they can be exercised by automated tests the usual way. And refactoring of models should be simpler, not harder than ordinary code, because with the better separation of concerns, changes are handled in a more localized way, reducing the chances for widespread changes.

“Finally, UML is a specific implementation technology that you seem to have committed to.”

First, it is different from conventional implementation technologies because it goes out of its way to be removed from mundane technical implementation details. In modeling, we strive not to over-specify a solution, thus preserving its generality and allowing it to be realized in different ways, effectively separating the general solution concerns (intentions) from concrete technology implementation concerns.

Second, I am not committed to UML, I will happily drop it for any better alternative (that was the whole point of this post!), according to the constraints I refer to.

“migration to some different technology quickly becomes infeasible”

That is one of the selling points of raising the level of abstraction. You don’t need to migrate as often, as you get farther from concrete implementation technologies, things are much more stable. And when you do have to migrate, you have way higher chances to be dealt with an automated transformation, as model compilers can make sense of the intent behind a model way more easily. Win-win.

“There’s quite a bit of interesting stuff going on that is quite hard to map to UML, such as erlang/go style concurrency, AOP and annotations, closures, map reduce, etc.”

Why do you say so? If those things can be done in ordinary OOPL, what is the difficulty with doing that with UML? Any concrete examples? UML activities are inherently parallel, you have to go out of your way to make things execute sequentially. UML supports annotations way before any programming language I know (stereotypes and tagged values). UML can be extended to support closures very easily (TextUML allows them, search the main page for “closures”). For things it does not have native constructs for, you can address the library-way instead of the language way, and if beneficial still provide native support in your notation (such as I did with closures). The language can be evolved to address gaps where it makes sense, but in most cases concrete implementation improvements are more properly taken advantage of by changing the transformation rules, not the models.

“Your text UML sample looks disturbingly like Delphi met Java. Needlessly verbose and I’ve seen nicer ways of saying hello world.”

That does not seem to be related to what we are talking about in this post, which is about executable modeling languages (and how UML seems to be the only option at this point), not about TextUML specifically. Actually, separation between abstract and concrete syntax (which may not even be specified) is another must-have for any replacement to UML, as it is something very valuable that it already does well.

That being said, I would be glad to hear your complaints/suggestions about the TextUML notation or the TextUML Toolkit by e-mail (rafael at this domain), twitter (abstratt), discussion forum or issue tracker.

Cheers,

Rafael

@Dominique, I’ve been following Simonyi and IP for about a decade. Unfortunately, beyond the papers he has never produced anything substantial in public. What they are doing exactly at intentional software is pretty much a big mystery. To me the time that has gone by without any substance suggests a pile of software that is not working as advertised (in the papers a decade ago). Meanwhile, Ruby seems to fill the gap quite nicely when it comes to DSLs and meta programming. Not the same thing of course but so much more practical right now.

@Vladimir model refactoring assumes that everything your model depends on in the real world is stable. It’s not unheard off but usually pretty much exclusively limited banking or insurance type IT projects, which incidentally is also a domain where DSLs have been used successfully. In the rest of the world, change is the norm in all layers of the system.

Note that I did not say anything about an implementation having to be open-source. My problem is with control and competition.

Thanks for the link, it was an interesting read.

The papers I have read say that there is a IP concrete technology implementation, and indeed, that’s the Simonyi’s one; it’s said to be used by Cap Gemini, for example, for some real-world test projects.

And, yes, I am sure it fails the last three criteria (open process, open standard, patent free)

But while I am an open source proponent, I still value non-open source products if they show enough added-value, and I am happy there is still some initiatives outside the all-inclusive-UML world, for drawing new interesting directions.

This being said, you may be interested to read my post about UML drawbacks I see:
“UML business hotspot is over (but modeling business still makes sense)”
http://www.jroller.com/dmdevito/entry/uml_business_hotspot_is_over

I find the ideas behind Intentional Programming very cool, but isn’t IP a paradigm instead of a concrete technology? The only concrete technology implementation I know of is by Simonyi’s Intentional Software, but I suspect that fails the last three criteria (open process, open standard, patent free).

Here are some differences with UML:
- IP standardizes the abstract level and authorizes as many view as one wants
- IP enables to integrate graphical descriptions and DSL
- with IP, the integration of the different views in relation with the abstract model is a problem from the start because there could be N views, but there is only one abstract model: and it’s good that this is a problem from the start, because users then don’t forget the final step: the code generation.
- etc.

“why do you need a modeling language to begin with and why does it need all those qualities?”

MDD allows developers to work at a more proper (higher) level of abstraction through a better separation of domain concerns from technological concerns.

“Who is the customer for your models and does he/she agree with the amount of resources you spend on creating them?”

I and my peer developers are the consumers of the models, just as with source code. The customer itself does not care how I build software, but does care if quality is more consistent, or if time to delivery is more predictable, or if takes less time for a new hire to become an effective contributor, or if it is easier to enhance the software to adapt to changes in the problem domain or technological requirements.

“After all, models just sit there and they are not executable code representing actual business value.”

My fault for not making it clearer from the beginning. My sole interest in UML is for creating executable models (MDD). Executable models don’t sit there. They are the real deal.

“For me the answer is, I don’t need a modeling language and I don’t really need anything beyond a whiteboard in terms of standardization, portability and what not. (…) If we have time and if it doesn’t eat too much into Friday afternoon beers.”

Totally agree if we are talking about models for documentation. I can’t care less. Totally disagree if we are talking about model-driven development, with executable models (which *is* indeed what I was talking about in this post).

“Agile and UML don’t go together unless you are faking either the modeling bit or the agile bit. (…) Tell tale signs that you are faking it: you have uml diagrams, each sprint is organized like a mini waterfall, you don’t have working code at the end of a sprint.”

Again, if talking about UML as communication/documentation notation, true, but not if talking about UML as programming language. See an old post on “UML modes“.

“MDA may seem like a good idea. However, you have to realize that with MDA you are just redefining what is your programming language.”

That is a fine perspective, but what is wrong with raising the level of abstraction of my ‘programming language’?

“So, you are merely programming in a different language (i.e. UML) and no longer modeling but coding. UML is a modeling language, it is not a programming language.”

Java, Ruby, C/C++, Smalltalk are just different 3G GPLs. There is a clear difference in level of abstraction between C and 8086 assembly. Same thing between UML and Java or Ruby. Re: modeling vs. programming, that is really relative. One can say a C source file is a model for an executable file, or that a UML model is the source while the generated Java code is object code. See “On code being model“.

Re: UML capability as a ‘programming’ language, I think it is powerful enough for what we need, and that is why I refuse to accept anything more ‘powerful’ (because that leads to over-specification).

“If you want to do MDA, you are probably better off with a domain specific language on top of a well defined framework.”

Why should I commit to a specific implementation technology when I have no intent to make use of it? Why should I lose my investment if I decide to target another implementation technology? Why should I choose Ruby for an accounting system, when Ruby’s technical capabilities have no bearing in my understanding of how to implement an accounting system? Why not use a pure, highly abstract language that forces me avoid adding more detail than necessary, instead of a full-fledged GPL that is bound to impose its technical idiosyncrasies?

“You will end up with less code to maintain, which is good.”

Not sure how MDD leads to more code. For me, MDD is the ultimate refactoring technology.

“This in a nutshell is why Ruby, Ruby on Rails and the dozen or so similar languages and frameworks are so popular lately. These solutions are ideal for quickly implementing frameworks and then co-evolving the framework with the scripting code that uses it. Much more light weight, much more easy to fit in an agile work style.”

Ignoring the fact that they have a more limited purpose, Ruby on Rails and Grails share much of the MDD mindset, using a convention-based programming model on top of GPLs, instead of a true modeling language.

As per MDA being a dirty word, I am working towards cleaning its name.

I apologize for dumping a bunch of links to older posts on you, just trying to make my point of view more clear without repeating myself too much.

Cheers,

Rafael

* it must be general purpose, not tailored to a specific architecture or style of software

Check

* it must not be tailored to an implementation language

Check

* it must be based on or compatible with the object paradigm

Check

* it must not be limited to one of the dominant aspects of software (state, structure, behavior)

Check

* it must be focused on executability/code generation (and thus suitable for MDD) as opposed to documentation/communication

Check

* it must be modular, and user extensions should be 1st class citizens

Check

* its specification should follow an open process

Check. Although I have to make a living out of it, I’m trying to keep ABSE as open as possible.

* it must not be owned/controlled by a single company

If it’s open, then there’s no “vendor lock-in”. But everything not yet clear at this point. Half-check!

* it must not require royalties for adoption/implementation

Check

Score : 8.5/9
So, ABSE is looking good so far per your requirements…

While I read your comment with much interest, I fundamentally disagree with much of what you said about MDD being coding, not modeling, that UML is not suitable as a MDD modeling language, that agile and UML don’t go together, or that DSLs are the only way to go. I hope to have time later today to write a more elaborate response.

Cheers.

For me the answer is, I don’t need a modeling language and I don’t really need anything beyond a whiteboard in terms of standardization, portability and what not. Draw and forget is my motto. If someone insists, photos get taken with my phone camera (though in my experience these photos are archived and never looked at). That’s it. I have some tools available if somenone needs a powerpoint friendly version. Though presenting hand drawn images is kind of cool in some places nowadays. I almost never use these tools because frankly nobody that matters gives a shit about UML diagrams where I work. At best uml diagrams are a checkbox in the documentation requirements list, a i.e. a low priority diagram in an artifact that we occasionally spit shine. If we have time and if it doesn’t eat too much into Friday afternoon beers.

Agile and UML don’t go together unless you are faking either the modeling bit or the agile bit. I’ve seen a lot of people faking both. Seriously, there is no modeling phase in an iterative & agile project. There’s iterative development of all the development artifacts (requirements, designs, code, tests, documentation). Iterative meaning working code at the end of each sprint (2-3 weeks). If you are wasting most of your sprint on modeling you are not delivering business value. So if you spent a lot of time modeling in a project either your models never change, i.e. you are doing waterfall, not agile, or you spend a shitload of time revising your models every sprint, meaning that you are wasting a lot of time better spend on something that will actually last, i.e. code. Tell tale signs that you are faking it: you have uml diagrams, each sprint is organized like a mini waterfall, you don’t have working code at the end of a sprint.

MDA may seem like a good idea. However, you have to realize that with MDA you are just redefining what is your programming language. So, you are merely programming in a different language (i.e. UML) and no longer modeling but coding. UML is a modeling language, it is not a programming language. Some would even argue it is suitable for neither purpose. If you want to do MDA, you are probably better off with a domain specific language on top of a well defined framework. You will end up with less code to maintain, which is good. This in a nutshell is why Ruby, Ruby on Rails and the dozen or so similar languages and frameworks are so popular lately. These solutions are ideal for quickly implementing frameworks and then co-evolving the framework with the scripting code that uses it. Much more light weight, much more easy to fit in an agile work style.

In most companies I have had the pleasure of working with, visiting, or otherwise had to deal with, MDA was a dirty word and the available rational rose licenses were exclusively used for writing documentation and creating pretty pictures for power point slides (despite the often equally nobel and misguided reasons for purchasing said licenses). Generally the more primitive the programming language used, the more need there is for documenting the decades of crap in the version control system and the more time and resources people seem to spend on documenting the crappy code they have. I know of several embedded software development companies where multiple attempts of introducing rational rose silver bullet type solutions have failed utterly and completely. On the other hand. introducing TDD, agile and other more sensible practices is the reason why some of these companies are still around.

Vlad,