https://sourceforge.net/apps/mediawiki/textuml/index.php?title=TextUML_Action_Language

It’s covering just some of the features now. Let me know if the documentation lacks clarity.

The abstract syntax is UML (action semantics) with an extension profile to support a few things not in UML (mostly closures). The concrete syntax/notation is not standard (there isn’t one).

I have been postponing documenting the syntax for behavior until someone asked for it…

Will let you know when that has been done. Meanwhile, the TextUML EBNF might help.

‘Meaningless’ might have been too harsh a word, I guess I could have chosen nicer terms such as ‘low-value’ or ‘dispensable’.
But when I think of UML as sketch and how people often use it, I can’t help but think of words such as ‘pointless’, ‘irrelevant’, ‘distracting’, and ‘wasteful’.

Why? Why meaningless? I could have agreed to something explaining that “UML as sketch” is inferior to the other two modes of UML operation as described by Fowler. But meaningless? Without even elaborating why? That’s hand waving.

I suspect most people working on new model-driven development tools (for instance, at Eclipse.org) totally ignore or have little knowledge of those products and that is a pity.

Exactly right! The Shlaer-Mellor execution tools having been doing it this way for years (e.g., http://www.kc.com/PRODUCTS/ and http://www.mentor.com/products/sm/model_development/). Execute the model interpretively to debug it and then compile to the target environment for deployment — possibly to several target environments.

Note that I didn’t actually use the term “code generation” above. This phrase implicitly assumes that the “code” is something different than your executable model, which automatically also implies that, in the end, it is the “generated code” that is the most important thing, not the model. If, on the other hand, you think of Executable UML like other programming languages, then the issue is interpretation or compilation, not interpretation or code generation — and the answer is, again, “Both!”, just as you say in your post. (See also my presentation http://slidesha.re/9zunfu, particularly slides 7 and 8.)

Of course, executing UML can be useful even when the goal is not programming. For example, if system engineer with a model in SysML would like to be able to execute, simulate and analyze his system model before committing it to the production engineers. In this case interpretation is a natural approach — though not necessarily the only one; one could still compile the model behind the scenes, to improve performance (I believe that IBM Rhapsody actually does this). (See also http://slidesha.re/biyqCV, slide 9.)

– Ed

no meu caso eu não usaria por que no momento estou utilizando tecnologias CMS. Meu foco atualmente não tem sido desenvolver aplicações. Mas cara… eu tenho um outro impedimento grave para não usar TextUML. O dificuldade é como eu transformo meu modelo criado no textuml em código que funcione. Isso não é só no caso do TextUML. Até com XText e MPS isso no meu ver é muito chato ou tem pouco material para o público “desenvolvedor final”. A utilização destes recursos fica disponível a um grupo limitado de desenvolvedores que por algum motivo conhecem muito da arquitetura do elipse. Resumidamente, utilizar o textuml e ainda gerar boa parte do sistema com apoio dele não é para amadores. Por um tempo eu bate muito a cabeça neste assunto a ponto de desencanar apesar de ser o meu tema técnico preferido.

Vc não concorda?

No espírito de entender melhor o público desenvolvedor: por que não usarias?

no momento não tenho planos de utilizar o TextUML e nem o AlphaSimple. Mas mesmo assim, não tem como negar - ambas soluções são muito inovadoras. É sempre legal ver as novidades de ambos projetos. Sempre surpreendem. Parabéns e continue assim.

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.

IMO people seem to be burnt by Case Tools, primarily, and by dogmatic MDA - which seems to end up in endless diagrams and no running system.
I like MDD’s pragmatic attitude - use models where they make sense - to heighten the abstraction level (which means very little to many new comers until they see real examples of it) and automate by generating a lot of tedious repetitive code. I totally agree with focusing on forward engineering and model is king.

I agree with those that complain that the learning curve is still too steep and it still doesn’t help that many MDD zealots are still too high on their UML bashing horse. Many examples of MDD simply miss the point of helping adapters get on board. People have experience with UML - let them use it where UML actually works.
IMO the hardcode MDD expert’s are too far ahead of them crowd to have a change of including them. I mean EMF, GMF and e.g. OpenArchitectureWare are extremely cool and versatile - but it’s still too complex and have a high learning curve before you’re productive. A lot, including me, have given up before reaching a point where we could actually get anything done.
We decided to not use EMF - not because we’re smarter than the guys who build EMF - but because we wanted something that was easier to use and thereby has a lower learning curve. It’s not as versatile as EMF, but so far we haven’t come a cross a project which wasn’t easily solvable using the current approach.

In order to spread MDD and attract new projects to use it, we instead tried to focus on where the major hurt these days are - In my perspective it still very much resolves around the domain model (being an internal or external).

This is where we have successfully helped customers adapt MDD by combining it with Domain Driven Design (DDD). We simply model their domain model in UML (using Class diagrams only) - and perform straight forward code generation of Java code with JPA/Hibernate annotations/specific code (or for instance WSDL, XML Schema for Webservice models).

Model is king and code can be regenerated time and time again - with the option to allow custom code extensions either through code generator extensions, through aspects, 3 level inheritance or some other approach (see http://www.slideshare.net/jeppec/building-a-lean-architecture-for-web-applications-using-domain-driven-design-model-driven-software-development).
With UML domain modeling the abstraction layer can be raised a lot - e.g. with introducing stereotypes like “history” or “versioned” which lets you annotate your model to indicate active history/temporal object pattern). Too many hard code MDD’s may laugh at this as being too little or too simplistic- but for a lot of new MDD adapters it’s a lot - It’s something that immediately gives reward - it’s easy to understand and evolve and it doesn’t try to interfere with domain logic. Start here, gain confidence and later you can introduce DSLs and other visual models based on something more fitting than what UML may have to offer.

Visual domain models are extremely good for overview and communication. We often sit down together with business expert which join in on the modeling because basic UML class diagrams, with a few stereotypes and perhaps a tagged value or two, are easy to comprehend and understand. No reason to understand meta or meta-meta

My 2 cents

/Jeppe

“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.

I actually find the MDA model very useful as a conceptual/philosophical framework. I won’t argue against your opinion of the suitability of UML as an executable modeling language, I assume you know mine.

Re: roles - not fundamentally different, but I argue that MDD provides for much better separation of concerns and rationalization of the work, making the separation of responsibilities more clear/feasible.

Re: “Creating reusable abstractions is a key discipline in software development, does it really matter that much whether you create libraries, languages, generators or interpreters?”

Again, I think MDD/DSM provide more powerful mechanisms for separating abstractions. People write OO-like in old style C. Still, there are significant benefits in using a proper OO language (even if it is C++).

“It’s just a tool and the whole process isn’t that much affected”

Hey, the whole process is the same since the time of the ENIAC.

“Maybe besides that usually my turnarounds suffer if I use too much code generation”

If you can execute your model, you don’t need to generate until you are happy with it.

“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

@Johan,
but how does those roles (generator developer, modeler) differ from people who built frameworks and libraries and people who use them?
Creating reusable abstractions is a key discipline in software development, does it really matter that much whether you create libraries, languages, generators or interpreters? In the end you’ll have to understand the problem to solve and find the right level of abstraction.
In general I find it strange to see MDD as an (holistic) approach to software development. It’s just a tool and the whole process isn’t that much affected. Maybe besides that usually my turnarounds suffer if I use too much code generation

* 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…

Nice points. I agree with most of them. However, I think your first two points needs more nuance. You’re right, programmers are still needed and business analyst cannot build everything with an MDD tool. But, roles do definitely change when using MDD (see http://www.theenterprisearchitect.eu/archive/2009/02/04/roles-in-model-driven-engineering ). Programmers will move to working on generators and maybe some technical parts of an application, modeling an application can be done by less-technical programmers or business engineers (or whatever we call it).

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,

I personally recommend to throw EMF in the bin because this project failed.
The best is to use Ecore with UML and just EMF as back-office rules engine.
EMOF is like the official OMG MOF and it is really very very powerful if used well.

btw, Great super bowl New Orleans win yesterday

Vlad,

EMF is just complicated enough to help solve complex problem, much like Java itself. Surely no one will argue that Java is simple! Furthermore, it’s clearly being used by a large and growing community; everything has to start somewhere. In any event, I’ll definitely avoid taking attitude advice from anyone who consider name calling an acceptable form of technical discourse.

I agree that it’s often and even typically very good to keep generated and hand written code completely separate. The point of my blog is that this doesn’t always come without a price of its own, e.g., I explained the cost of the “four class pattern.” Note Mint does a very nice job with filters to show only the hand written code. A point to take away from that is that good tools can do an excellent job solving problems in innovative ways; one of the basic tenets of MDD. That being said, most of the open source tools at Eclipse are generally adequate at best…

Here’s something I’ve asserted many times: if you started from scratch and tried to solve all the problems that EMF has already solved, you’d end up with something isomorphic to EMF. I.e., it won’t be simpler, just different.

Another issue (major, in my opinion) is that burden to tell apart generated from manually written code is now on developers. Talking about code generation in EMF, I much prefer the approach used by UML2, where whenever there is need for handwritten code, the generated code delegates to a separate class. I know that when the UML2 metamodel implementation provides some less trivial behavior, the code will be in the corresponding XYZOperations class. I can safely ignore the automatically generated implementations of metaclasses (which I believe is most of the code). That clear and simple convention significantly reduces the effort for understanding the UML2 code base.

I don’t agree the absence of round-trip engineering makes models redundant. The *code* is redundant, as it can be always regenerated from the models.

“Yes you do need some models but not to the level that mdd requires”

“(…) diagrams don’t get updated when people get short of time.”

“That leaves only one artifact that is indeed the truth - the code.”

These sentences are very telling. They tell me you are not doing MDD, but instead you are using models for sketching, communicating and documenting designs. That is fine, even though not my piece of cake, many (most) people use models that way, but that (and the problem you describe) has nothing to do with MDD. I would go as far as saying that approach to modeling is what creates a lot of misconceptions about MDD.

Finally, I would be very interested in understanding what you meant by “incomprehensible models (that are harder to read than code)”. What “incomprehensible models” look like?

As a result, Eclipse is on a track which is alienating a large part of its user base. I think it is safe to say, no one likes to be forced to use a technology because a mere few manage to pull some strings to ‘educate the misguided’.

EMF is an extremely overly complicated technology, and clearly not in a state yet to be forced on a larger public. I find comments on new EMF sub-project announcements, such as ‘hoping to read the English translation, soon’, particularly relevant and amusing.

Until that time, I will be happy to see it evolve over time into something human-apprehensible. EMF belongs to an in-crowd. If that group wishes to gain some larger appeal and respect, I suggest they reconsider their attitude.

http://ed-merks.blogspot.com/2008/10/hand-written-and-generated-code-never.html

We’ve been evolving models such as Ecore and GenModel for almost ten years now. We’ve modified the models and regenerated, e.g., adding generics to Ecore was a very significant change, we’ve modified the generated code to implement derived features, and we’ve evolved the general purpose templates to improve the generated patterns, e.g., boolean and enums stored as flags. Those who say it can’t be done are simply wrong.

On the business side; models mean little to me. A Feature driven process details to me what to expect in terms of functionality and when. A clear winner over models which to me are nothing but part of the process of making an application; not an acceptable deliverable.

As for your myths, its hard to say. To me MDD ultimately must include round trip, though I understand it may not currently. The others I am happy to label as myths.

Having a project setting for whether to automatically generate ids as GUIDs or derive from qualified names is a good idea, and should be easy to implement.

To allow some sort of annotation for declaring ids manually would be possible, but I wonder how people would use that.

Feel free to enter your suggestions as feature requests on the project tracker: http://abstratt.com/issues/

Cheers,

Rafael

It was great to meet you in Toronto. Thank you for coming so far to attend and I’m glad we were able buy you that beer.

I like your idea of having short and long presentations in a single track. Something to consider for future events.

Greetings,
Max

For example I have UML domain model. It contains annotations for: DB schema (tables, columns), ORM code (Hibernate/JPA/Transactions), Web pages (UI artifacts customization). It can be used for generation of a Java code, DB schema, services code, Web pages. This code then can be reverse engineered back to the model (at least at DB/ORM level since its based on a strictly defined specifications)

An interesting statement; one could compare http://en.wikipedia.org/wiki/Central_dogma_of_molecular_biology .

The idea of RTE seems to be that models can be built inductively by looking at existing solutions as implemented, warts and all. The idea of code as a mere instance of an abstract model - another kind of view - is appealing, but it leads to a kind of Platonic ideal of the model. I want my models to be living things that benefit from the successes and failures of implementation - shaped by the metainformation of interaction with the real world. I do agree that one instance isn’t enough to build a high-resolution model, but I’m not sure that a lot can’t be learned by examining many instances as part of the processes you’re modelling.

You’re entirely correct that that’s not at all the same thing as equating model and code, of course.

Great point about the appropriate application of 3GLs btw.

To be pedantic, note that the TextUML notation is compiled into UML models, not reversed engineered.

The notation compiler could be implemented on any language, the fact that the TextUML Toolkit runs on Java is an implementation detail of that specific tool. The choice of using the Java class library and Eclipse frameworks is what enabled the development of the Toolkit by a single guy working on his spare time.

http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

Maybe this concept bring us “code is model”. I agree that higher levels of abstraction could help us, but also agree that not for every aspect of the system being developed.

On the other hand a basic distinction between code and model for me is that latter is/should be a built in a more declarative manner than imperative.

I also think that the mantra “code is a model, too” does not help very much, because it makes people think that code and model are on the same level of abstraction.

I think what Harry really meant was that code at one level will be a model to a corresponding artifact in the next (lower) level.

Of course, there are situations in which code and model are on the same level. Just think of traditional UML modeling (a class diagram is just a different view of the code)

Well, even in the case of UML class diagrams, there is an increase in the level of abstraction. Think of things like associations (with shared/composite aggregation), multiplicities (with ordering/uniqueness), subsetting/redefinition of properties. None of those things can be represented in any of the OO languages I know of.

I agree with your opinion that you just cannot use round-trip engineering in MDSD, as computers (still) are not able to abstract. Model driven software development is a forward-only process for this very reason. Fortunately, most people understand this point as soon as you tell them.

I also think that the mantra “code is a model, too” does not help very much, because it makes people think that code and model are on the same level of abstraction. Of course, there are situations in which code and model are on the same level. Just think of traditional UML modeling (a class diagram is just a different view of the code).

To me, modeling is a means to express concepts of the real world in a way that both a developer and a business person can understand it. It’s really a meet-in-the-middle approach. Domain Specific Languages (DSLs) can help to achieve just that. I am not convinced that UML can deliver on this, which is why I usually use Xtext (http://www.xtext.org) to achieve this.

Lots of things can be said on the topic (and I think we should do so) but to put it as simple as possible I can explain the difference as follows:

TextUML is just another representation for the UML concepts but JRuby has nothing to do with being a representation for JMV bytecode. A machine microcode is at the bottom of the abstration layer chain and almost anything can be built on top of it. On the other hand TextUML (or any concrete syntax) does to add anything to or does not build a really new abstration level on top of UML (or to a abstract syntax/metamodel). So it’s important to distinguish a metamodel and a microcode.

Yes, UML is a language. But TextUML per se is not a real language, instead being just a shallow notation built on top of the UML semantics and abstract syntax.

Re: Java or Ruby serving as modeling languages - well, if you limit yourself to simple concepts such as classes, their structural features, and inheritance, yes, Ruby or Java can make do as modeling languages. But for sound OO modeling, you need much more: associations (with composition/aggregation semantics), multiplicities, and things from other modeling aspects such as states and transitions. You can try to mimic that with hacks in Java and Ruby, but a modeler will be better served if those features are natively supported by the modeling language.

That, assuming your creating models to support model-driven development. Totally agreeing with “choosing the right language for the right task”, the best language will be the one that better supports your modeling needs.

[Ruby]
class Car
def drive(speed); end
def stop; end
def accelerate; end
end

[TextUML]
class Car
operation drive(speed:Integer);
operation stop();
operation accelerate();
end;

See what I mean? That is why I dare question the notion of using UML, if you can use the implementatino language directly, without loosing semantics. Of course, there are features of one language over another that let you express “semantically rich” elements more easily than in another language — but that IMHO is merely a matter of choosing the right language for the right task.

The effort required was not trivial though, and since graphical visualization is more a nice to have than a key feature, I decided to drop that idea and integrated with Graphviz via EclipseGraphviz instead.

Actually, the TextUML renderer (the component that generates TextUML source from UML2 models) is pretty much self-contained so I would say it is ready for integration into Papyrus. It only needs to be wired into whatever framework Papyrus offers for third-party diagram providers. Not sure how easy or hard that part is.

Cheers,

Rafael

Great!
“Reading models created by other UML tools using the TextUML notation” could provide an excellent way to integrate TextUML as an Eclipse Papyrus Diagram.

Cheers,
Jérôme.

http://blogs.the451group.com/opensource/2008/10/13/open-source-is-not-a-business-model/

But there are many other interesting posts on that blog. Obligatory read for anyone in the business of software considering the open source venue.