Productivity of UML

Found an old discussion on the MDSN site about a study on the productivity of UML, brought up by the DSM folks. You can see some of the common caveats raised in this comment by MetaCase’s Steve Kelly. Please read his points and come back here.

I actually didn’t notice it was an old thread and replied to it. Call me cheap, but I hate perfectly good arguments going to waste on a dead thread, so I am recycling my original response (now deleted) here as a blog post.

1) repeat with me, UML is not a graphical language – it has a graphical notation, but others are allowed. Criticism of UML as a whole based on the productivity issues around the graphical notation is cherry picking or (at best) a misinformed opinion. If you don’t like the default notation, create one (like we did!) to suit your taste (and it will still be UML). The specs are public, and there are good open source implementations of the metamodel, that are used by many tools.

2) you don’t need to give up on the semantics of UML to map a modeled class to multiple artifacts. That is just plain OO design mapping to real-world implementation technologies. UML is an OO language first and foremost.

3) There is no need to mix languages, UML has support for both structural and behavioral modeling (since 2002!). Action languages are not (or don’t have to be) “other languages” – but just a textual notation on top of the existing abstract syntax and semantics. That is not a marketing ploy, incorporating elements of the Shlaer-Mellor approach was just a sound strategic decision that made UML much better.

4) Annotations (or stereotypes) is an established (see C#, Java) and cost effective way of tailoring a general purpose language to one’s needs. Not everything calls for a DSL. Both approaches have pros and cons, one has to pick what is best for the situation at hand.

5) All the stories of failure or limited success with generating code from UML models I heard or read are caused by the decision of ignoring behavioral modeling in UML and doing partial code generation. That is a losing proposition, no matter the modeling language. Again, just like the notation issue, analyzing UML productivity based exclusively on those narrow minded cases is at best spreading misinformation. Kudos to MetaCase for promoting full code generation, that is the way to go. But full code generation is not an exclusivity of DSL, the Executable UML folk (and other modeling communities) have been doing it successfully for a long time as well.

Can we move away from the pissing contest between modeling approaches? That got old ages ago. There are way more commonalities than differences between DSM and executable modeling with GPLs like UML, productivity gains included. There is room for both approaches, and it would not be wise to limit oneself to one or another.

What is your opinion? Are you still using old school UML and limiting yourself to generating stubs? Why on earth haven’t you moved to the new world of executable models yet?

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Anti-patterns in code generation – Part I

So it finally hits Ted, The Enterprise Developer: all his enterprise applications consisted of the same architectural style applied ad nauseum to each of the entities they dealt with. And Ted asks himself: “why am I wasting so much time of my life doing the same stuff again and again, for each new application, module or entity in the system? The implementation is always the same, only the data model and business rules change from entity to entity!”

The Epiphany

So Ted figures: “just like I write code to test my code, I will write code to write my code!”.

Ted decides that, for his next project, he will take the approach of code generation. Ted is going to model all domain entities as UML classes, and have the code generator produce not only the Java (or C#, or whatever) classes, properties, relationships and methods, but all the boilerplate that goes along with it (constructors, getters, setters, lazy initialization, etc). “This is going to be awesome.”

The Compromise

One of the first things Ted realizes is that since his UML models are pretty dumb and contain no behavior (“UML models can have no behavior, right?”), there is no way to fully generate the code. Bummer.

“Wait a minute, that is not totally true.” Ted’s models contain operation names, parameter lists and return types, so Ted can at least generate empty methods (stubs), complete with Javadoc with the operation description. “This *is* awesome!”

Ted still has all these empty methods that need to be filled in for the application to be fully functional. So he starts filling them in with handwritten code.

Reality Kicks In

Things are looking great. Ted is already filling in the stubbed methods for the tenth entity in the system. But then he realizes there is a problem in the generated code. It would be an easy fix in his generator, and rerunning it will fix the problem everywhere (isn’t that beautiful?). However, Ted would end up losing all changes he had made so far. Argh.

Any way out?

Ted thinks: “shoot, this was going so well, look at how much code I produced in so little time. There must be a solution for this.”

He almost feels like backing up his current code somewhere, regenerating the code (losing his changes) with the new generator, and then adding his handwritten code back (“Just this once!”)”. But he knows better. At some point he will need to regenerate the code again (and then again, and again…), and his team won’t buy the approach if it is that complicated to fix problems or to react to changes. It will look pretty bad.

He opens a new browser tab, and starts thinking about the best search terms he should use to search for a solution to this problem…

In the next episode, Ted, The Enterprise Developer, continues his saga in search for a fix to his (currently) broken approach to code generation. If you have any ideas of what he should try next, let me know in the comments.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Generating code in Maven projects with the AlphaSimple plug-in

This just in: you can now generate code for AlphaSimple projects from within your Maven-based project build! That gives you a convenient way of getting the code generated by AlphaSimple into your (and your teammates’) development environment, or in your automated builds.

How do you do that? Let’s see.

Step 0: create your model(s) and template(s)

You must have an existing project in AlphaSimple. This was the subject of a previous post. Read it first if you don’t know how to create models and templates in AlphaSimple. Make sure your project is shared.

Feeling lazy?

Okay… just copy and paste the pom definition from this file into your pom.xml. You can skip down to step 3, and it will work out of the box (generating code from a pre-existing shared project).

Step 1: Enable the Abstratt repository

<project ...>
    <name>Abstratt Technologies Maven repository</name>

This is required because the AlphaSimple Maven plug-in is not available from Maven Central or other public repository (yet).

Step 2: Include the AlphaSimple Maven plugin in your pom.xml

<project ...>

Which in summary is executing the generate goal of the AlphaSimple plugin during the generate-sources phase of the Maven lifecycle.

In the example above, the plug-in is configured to execute the generator at, for the AlphaSimple sample project (see this post for how to obtain a similar URI for your own project).

Also, files will be generated at the specified location (which in the example above will map to target/generated-src/main/java). In order for them to be seen by the Java compiler, that location must be configured as a source directory, for instance, by specifying a non-standard source location in your module:

<project ...>

Step 3: run Maven

    mvn clean generate-sources

will get you something like this:

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building AlphaSimple Code Generation example 0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ com.alphasimple.examples.pojo ---
[INFO] Deleting file set: C:devcom.alphasimple.examples.pojotarget (included: [**], excluded: [])
[INFO] --- com.abstratt.alphasimple.mojo:1.0-SNAPSHOT:generate (default) @ com.alphasimple.examples.pojo ---
[INFO] Generating at
[INFO] Generating at
[INFO] Generating at
[INFO] Generating at
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.486s
[INFO] Finished at: Sun Mar 06 16:48:36 PST 2011
[INFO] Final Memory: 2M/58M
[INFO] ------------------------------------------------------------------------

The generate-sources phase or any other phase that follows (such as compile, package, install etc see lifecycle reference) will cause the code to be regenerated. As you make changes to your models or templates in AlphaSimple, further runs of the generate goal will take those changes into account.

In the case of generating Java code, you will want to include at least the compile phase so you can tell whether the generated code is valid (if you get an error about generics not allowed in source level 3, see this).

What just happened?

The AlphaSimple Maven plugin does not know how to generate code, nor has dependencies on other Maven artifacts that do. All it does is to hit the code generation endpoint in the AlphaSimple REST API, and request code to be generated for the chosen target platform. It then just extracts that ZIP stream into the chosen location in the file system.

Once you create your models and templates in AlphaSimple (see previous post), it is very easy to include the generated code in your Maven-based projects. All you need to do is to include an execution of the AlphaSimple plug-in and point it to the generator of your choice. It is that easy. But don’t take our word for it, try it yourself and give us your opinion!

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Generating code from UML models using AlphaSimple and StringTemplate

We just released a new build of AlphaSimple with basic support for customized code generation using templates, more specifically, using StringTemplate templates. Let’s take a quick tour:

Create a model in AlphaSimple

Create your model in AlphaSimple. If you need help with the notation, check the tutorial. You can just start with the default contents you get when creating a new project:

package NewProject;

class NewProject
    /* attributes */
    attribute text : String;
    attribute check : Boolean;
    attribute number : Integer[0,1];
    attribute date : Date[0,1];
    /* relationships */
    /* actions */
    operation toggle();
        self.check := not self.check;
    /* queries */


Remember to save your file.

Create a template

AlphaSimple supports StringTemplate as template language (check out this 5-minute introduction). In order to define a template in your AlphaSimple project, create a file with the .stg extension (in StringTemplate lingo, it is a template group file). You can use the example below, which for every class in a model, creates a text file that shows its name, and the names of its attributes and operations:

group simple;

outputPath(class) ::= <<
<! The 'outputPath' template is optional and determines the path of the file generated (the default is the class name) !>

contents(class) ::= <<
<! The 'contents' template is mandatory and is the entry point for generating the contents of the file from a class. !>
Class: <>

Attributes: <class.ownedAttributes:{attr|<>};separator=", ">

Operations: <class.ownedOperations:{op|<>};separator=", ">

Again, remember to save this file.

Declare your custom template

To enable custom templates, you need to create an AlphaSimple configuration file ( It is a configuration file that drives the compiler and code generation in AlphaSimple. Your file can be as simple as this:

# the template implementation we use

# the templates supported (always<name>.template=<template file name>

Both entries are mandatory. Ensure the line declaring the template matches the name you chose when creating the template file. Save this file.

Test your template

In order to test your custom template, if you have been using a guest account, you will need to sign up first (it’s free). Your project contents will be preserved.

First, publish your project (see button in the editor). Then, from your list of projects (“My Projects”), share your project (open lock button). For any future modifications to model, template or configuration file, you will need to publish your changes again. This will not be required in the future.

We are almost there. Since there is no UI for triggering custom generation yet, you will need to use the REST API, which is quite easy. Find out the numeric id of your project (from any link pointing to it). Then hit a URI with this shape:<username>-<project-id>/

For instance, for project 515, belonging to user simple, the URI would be:

which returns:

<workspace packageCount='1' timestamp='1298449947000'>
  <model name='NewProject.uml'
  <properties name='' uri=''/>
  <source name='NewProject' uri=''/>
  <source name='simple.stg' uri=''/>
  <generator platform="jpa" uri=""/>
  <generator platform="pojo" uri=""/>
  <generator platform="simple" uri=""/>
  <renderer uri=""/>

which gives you access to all the objects that AlphaSimple project has: source files (model and template), the configuration file, the generated UML model and corresponding class diagram, and, what we are mostly interested here, all generators available. Note that it includes not only a generator for the custom template, but some other built-in generators as well. But lets ignore those for now, and open the generator URI for our custom template (named “simple”). Voila, this is what you should see:

Class: NewProject

Attributes: text, check, number, date

Operations: toggle


We hope this very simple example gave you an idea of how you can generate code from UML models using AlphaSimple and StringTemplate (even if it doesn’t really generate actual code). In the example template, we only navigate from a class to its operations and attributes, and access their names, but your template has virtually any information from the underlying UML model available to generate from.

If you would like to see more interesting models and actual code generation templates, browse the shared project area. For now, there is currently just one project with an elaborate template. Clone it and model (and generate) away. If you have any feedback, just post a comment here or check the AlphaSimple contact page.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

TextUML Toolkit 1.7 RC1 now available!

The first release candidate build for TextUML Toolkit 1.7 is now available! If you already have the Toolkit already installed, please update now. If you don’t, the easiest way to install it is via the marketplace client (built into Eclipse 3.6). Or else, point the Eclipse update manager to

Here is a summary of the new features:

  • the editor will auto-format your source files as you save them (you must turn this feature on via the TextUML preference page)
  • fine control over the outline contents (you can toggle attributes, operations and inner associations on and off via the TextUML preference page) – thanks to Attila Bak for contributing this feature.
  • notation features: you can apply stereotypes to parameters, and you can declare attributes as read-only – also, attributes are now public by default.

More details here.

If you find any issues, please let us know (here or on the forum) so we can fix them before declaring a release.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Model-driven Development with Executable UML models

Last November I did a lecture on Model-driven Development with Executable UML models to a class of Software Engineering undergrad students at UVic. Here are the slides:

I think it gives a good summary of my views on model driven development (with Executable UML or not):

  • even though problem domains are typically not very complex, enterprise software is complex due to the abundance of secondary crosscutting concerns (persistence, concurrency, security, transactions etc)
  • there are two dominant dimensions in enterprise software: business domain concerns and technological concerns
  • they are completely different in nature (change rate, abstraction level) and require different approaches (tools, skills, reuse)
  • MDD is a strategy that handles well that divide: models address business domain concerns, PIM->PSM transformation addresses technological concerns
  • brainstorming, communication, documentation and understanding (rev. engineering) are not primary goals of MDD – to produce running code in a productive and rational way is
  • models in MDD must be well-formed, precise, complete, executable, technology independent
  • graphical representations are not suitable for executable modeling (textual notations are much better)
  • diagrams != models, text != code (that would look good on a t-shirt!)

I guess those who know me won’t have seen anything new above (these ideas make the very foundations of the TextUML Toolkit and AlphaSimple).

Do you agree with those positions?

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Using UML2 in a server-side application? Read this.

For those of you who didn’t know, AlphaSimple, our web-based modeling tool, is strongly based on Eclipse technologies:

  • the server runs Equinox with the web server (Jetty) running as an OSGi bundle
  • we use UML2 for building models (during model compilation), or for traversing them for execution, code generation, diagram rendering etc

UML2 is quite a piece of software. It implements the huge UML spec more thoroughly than any other alternative library (open source or not). Much of what I learned about UML in the last 5 years I learned by dealing with the UML2 API. Kenn Hussey and James Bruck have done a great job on the front of compliance.

On the not-so-great side, development seems to have stopped. IBM, which founded (and funded) the project, apparently pulled the plug last year. The current UML version supported is 2.2 whereas UML 2.4 is coming out soon. The newsgroup has no one that actually knows the code answering questions (I try, but I am far from familiar with the internals of UML2). This is not only an impediment to adoption, but may scare existing adopters away.

But even ignoring those strategic issues, there are technical problems as well: the one we faced with UML2 is thread-safety, which currently makes it unusable for long-running/highly concurrent applications. For a server-side application like AlphaSimple, that is a showstopper. Case at hand: even if we create, load and dispose UML2 resources in a single thread, internally UML2 uses a singleton object that caches cross-references between elements – for all models, and across all threads. That  introduces unnecessary contention between threads that are doing fundamentally unrelated work, but worse, this cache is not fully thread-safe (see bugs 335135 and 332057), and I suspect can’t be made thread-safe by design.

Q: how does one deal with showstoppers? A: with drastic measures.

In the case of AlphaSimple, where we explicitly unload all UML2/EMF resources in the same thread we loaded them (instead of relying on garbage collection), there really is no place for a singleton complex data structure that is intensively used for anything model-related. So our drastic measure (which I am not proud of) was to patch UML2 so the cache adapter is thread specific (by replacing CacheAdapter.INSTANCE with CacheAdapter.getInstance() and returning a thread-specific “singleton”). Luckily the changes required were quite small:


retrieving revision 1.43
diff -r1.43
< 		return CacheAdapter.INSTANCE;
> 		//RC - hack to avoid thread safety issues with CacheAdapter
> 		return CacheAdapter.getInstance();


retrieving revision 1.88
diff -r1.88
< 			CacheAdapter.INSTANCE.adapt(stereotypeApplication);
> 			//RC - hack to avoid thread safety issues with CacheAdapter
> 			CacheAdapter.getInstance().adapt(stereotypeApplication);


retrieving revision 1.26
diff -r1.26
< 	public static final CacheAdapter INSTANCE = createCacheAdapter();
> 	//RC - hack to avoid thread safety issues with CacheAdapter
> 	private static final ThreadLocal<CacheAdapter> INSTANCE = new ThreadLocal<CacheAdapter>() {
> 		protected CacheAdapter initialValue() {
> 			return createCacheAdapter();
> 		}
> 	};
> 	public static CacheAdapter getInstance() {
> 		return INSTANCE.get();
> 	}

This is not a real fix in the sense that it may not work for all applications – for instance, applications that read/create models across different threads. So now we need to manage this patch instead of just getting UML2 from the target platform. But comparing to having a server that keeps failing, we are quite happy with that.

If you can see an issue with this workaround, or if you think I am wrong by believing UML2 cannot be made thread-safe without radical modifications, speak up.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

The value of UML (or lack thereof) in the development process

[What follows was adapted from a discussion on LinkedIn on why companies developing software don't use UML more]

UML proponents argue that by using UML one gains the ability to properly represent important knowledge on the problem domain and intended solution design. That leads to good things such as improved communication and better quality of the software.

I certainly don’t question that. The ability of devising a solution at the right level of abstraction is extremely important. Yet, that on its own is not enough. It doesn’t help if the language that allows you to specify a solution at the right level of abstraction does not lead to running code (via code generation or direct execution). If one has to specify a solution again by implementing by hand (say, in Java or C#) what the model describes (i.e. using the model as a reference), that greatly offsets any gains from modeling. As the agilists say: Don’t Repeat Yourself. I won’t bore you with the consequences of breaking that simple rule, it must be obvious to any developer worth their salt.

If you are going to be pragmatic, and you cannot generate running code from your models, from a developer’s point of view, there is no much value for UML in the development process.

Developers play an increasingly important role in software product development. Non-executable UML models are seen as fluff, an unnecessary burden to software developers, and hence the poor reputation with that crowd, as the majority of the places using UML is unfortunately using it that way.

I see two solutions for this: either get models to be executable, or get programming languages to support a higher level of abstraction. Even though I am a believer of the former (and our work at Abstratt follows that approach – see AlphaSimple and TextUML Toolkit), I won’t be surprised if the latter ends up being the winning approach (see RAD frameworks such as Grails and Rails).

Do you agree? Which approach do you prefer? Why?

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Take control over UML class diagrams in AlphaSimple

As recently announced, shared models in AlphaSimple now sport UML class diagrams thanks to Graphviz support in the Google Charts API .

What I didn’t mention is that you can customize how diagrams are rendered by specifying query parameters on the image URL. For instance, compare the basic diagram from the previous post with the customized diagram below (click on it to see the URL). Can you spot the differences? :)

Here are all supported options:

  • showAssociationEndOwnership (boolean)
  • showStructuralFeatureVisibility (boolean)
  • showAssociationEndMultiplicity (boolean)
  • showAssociationName (boolean)
  • showAssociationEndName (boolean)
  • showClassifierCompartmentForPackage (Current, Immediate, Any)
  • showClassifierStereotypes (boolean)
  • showElementsInOtherPackage (Never, Immediate, Always)
  • showEmptyClassifierCompartments (NotEmpty, Never, Always)
  • showFeatureStereotypes (boolean)
  • showParameterDirection (boolean)
  • showPrimitives (boolean)
  • showRelationshipStereotypes (boolean)

Give it a try (don’t forget you need to share your projects, and republish for changes to become visible to others). Are there more control options you would like to see?

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

On model-to-model transformations

There was some strong (but polite) reaction to some comments I made about the role of model-to-model (M2M) transformations in model-driven development.

My thinking is that what really matters to modeling users (i.e. developers) is that:

  1. they can “program” (i.e. model) at the right level of abstraction, with proper separation of concerns
  2. they can automatically produce running code from those models without further manual elaboration

In that context, M2M is not a requirement. That is not to say that to support #2 above, tools cannot use model-to-model transformations. But that is probably just an implementation detail of that tool, all that modeling users care is that they are able to model their solutions and produce working applications. Of course, modeling experts will be interested in less mundane things, and more advanced aspects of modeling.

Also, my comments were about model-driven development (MDD), and not model-driven engineering (it seems most people disagreeing with me are from the MDE camp). To be honest, I didn’t even know what MDE meant until recently (and I know that MDE contains MDD), and have just a superficial grasp now. To be even more honest, I am not interested in the possibilities of the larger MDE field. At least not for now. I will explain.

You see, I think we still live in the dark ages of software development. I want that situation to change, and the most obvious single thing that will let us do that is to move away from general purpose 3GLs to the next level, where developers can express themselves at the right level of abstraction, and businesses can preserve their investment in understanding their domain while at the same time being able to take advantage of technological innovation. Hence, my deep interest in making MDD mainstream.

I see value in the things beyond MDD that MDE seems to be concerned with (mining existing systems for models, model-level optimization). I just don’t think they are essential for MDD to succeed. Thus, I prefer to just cross that stuff off for now. We need to lower the barrier to adoption as much as we can, and we need to focus our efforts on the essentials. The less concepts we need to cram into people’s minds in order to take MDD to the mainstream, the better. It is already hard enough to get buy-in for MDD (even from very smart developers) as it is now. It does not matter how powerful model technology can be, if it never becomes accessible to the people that create most of the software in the world.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Model interpretation vs. code generation? Both.

Model interpretation vs. code generation? There were recently two interesting posts on this topic, both generating interesting discussions. I am not going to try to define or do an analysis of pros and cons of each approach as those two articles already do a good job at that. What I have to add is that if you use model-driven development, even if you have decided for code generation to take an application to production, it still makes a lot of sense to adopt model interpretation during development time.

For one, model interpretation allows you to execute a model with the fastest turnaround. If the model is valid, it is ready to run. Model interpretation allows you to:

  • play with your model as you go (for instance, using a dynamically generated UI, like AlphaSimple does)
  • run automated tests against it
  • debug it

All without having to generate code to some target platform, which often involves multiple steps of transformation (generating source code, compiling source code to object code, linking with static libraries, regenerating the database schema, redeploying to the application server/emulator, etc).

But it is not just a matter of turnaround. It really makes a lot more sense:

  • you and other stakeholders can play with the model on day 1. No need to commit to a specific target platform, or develop or buy code generators, when all you want to validate is the model itself and whether it satisfies the requirements from the point of view of the domain. Heck, you might not even know yet your target platform!
  • failures during automated model testing expose problems that are clearly in the model, not in the code generation. And there is no need to try to trace back from the generated artifact where the failure occurred back to model element that originated it, which is often hard (and is a common drawback raised against model-driven development);
  • debugging the model itself prevents the debugging context from being littered with runtime information related to implementation concerns. Anyone debugging Java code in enterprise applications will relate to that, where most of the frames on the execution stack belong to 3rd-party middleware code for things such as remoting, security, concurrency etc, making it really hard to find a stack frame with your own code.

Model-driven development is really all about separation of concerns, obviously with a strong focus on models. Forcing one to generate code all the way to the target platform before models can be tried, tested or debugged misses that important point. Not only it is inefficient in terms of turnaround, it also adds a lot of clutter that gets in the way of how one understands the models.

In summary, regardless what strategy you choose for building and deploying your application, I strongly believe model interpretation provides a much more natural and efficient way for developing the models themselves.

What are your thoughts?

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

TextUML Toolkit 1.6 declared!

The TextUML Toolkit version 1.6 has been released. It is the same RC1 build mentioned here a week ago. The listing on the Eclipse Marketplace has been updated, so in addition to the regular update site (, if you are using Eclipse 3.6, you can get it even more conveniently using the brand new Eclipse Marketplace Client.

Take a look at the new notation features:

  • preconditions on operations
operation withdraw(amount : Real);
precondition { amount > 0 and amount < self.balance }
    self.balance := self.balance - amount;
  • derived properties
reference employees : Employee[*]

/* calculated field */
derived attribute employeeCount : Integer := ():Integer { return self->employees.size() };
  • initial values on properties
attribute available : Boolean := true;

You can also try these new features online on AlphaSimple. Sign up or start a guest session to create, validate and run your models on the spot, there is nothing to install!

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

TextUML Toolkit 1.6 RC1 is now available

TextUML Toolkit 1.6 RC1 is now available! You can install it using the Marketplace Client or by pointing Eclipse to the update site:

If you find any problems installing this build, please let us know asap so it can be addressed before the final release.

New features

Much of the work in this release went into improving the model building infrastructure to be even more notation agnostic. That work is still ongoing and should be completed in 1.7. But there were plenty of user-facing feature additions as well:

  • preconditions on operations (2986923 and 3002571)
  • support for a default notation (so file extensions can be optional) (2995372)
  • support for implicitly applying profiles/stereotypes (so models are less verbose) (2981580)
  • support for derived properties (2928428)
  • support for initial values in properties (2115439)
  • advanced features (closures, constraints) are now implemented using profiles instead of metamodel extensions (2933692)

In other news

The reason it took so long for a new TextUML Toolkit release to come about was that I have been busy working on AlphaSimple, which went on public beta today. AlphaSimple is an online tool for domain-driven prototyping that currently uses TextUML as modeling notation. Thus, AlphaSimple is also the driving force behind most of the changes that happened in the 1.6 cycle, and you can try them right away by starting a guest session and studying the example projects.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

UML may suck, but is there anything better?

UML has been getting a lot of criticism from all sides, even from the modeling community. Sure, it has its warts:

  • it is a huge language, that wants to be all things to all kinds of people (business analysts, designers, developers, users)
  • it has a specification that is lengthy, hard to navigate and often vague, incomplete or inconsistent
  • it is modular, but its composition mechanism (package merging) is esoteric and not well understood by most
  • it is extensible, but language extensions (profiles and stereotypes) are 2nd-class citizens
  • it lacks a reference implementation
  • its model interchange specification is so vague that often two valid implementations won’t work with each other
  • its committees work behind closed doors, there is no opportunity for non-members to provide feedback on specifications while they are in progress (membership is paid)
  • <add your own grudges here>

However, even though I see a lot of room for improvement, I still don’t think there is anything better out there. The more I become familiar with the UML specification, the more impressed I am about its completeness, and how issues I had never thought about before were dealt with by its designers. And it seems that the OMG recognizes some of the issues I raised above as shortcomings and is working towards addressing them. Unfortunately, some fundamental problems are likely to remain.

In my opinion (hey, this is my blog!), for a modeling language to beat UML:

  • it must be general purpose, not tailored to a specific architecture or style of software
  • it must not be tailored to an implementation language
  • it must be based on or compatible with the object paradigm
  • it must not be limited to one of the dominant aspects of software (state, structure, behavior)
  • it must be focused on executability/code generation (and thus suitable for MDD) as opposed to documentation/communication
  • it must be modular, and user extensions should be 1st class citizens
  • its specification should follow an open process
  • it must not be owned/controlled by a single company
  • it must not require royalties for adoption/implementation

My suspicion is that the next modeling language that will beat the UML as we know today is the future major release of UML. Honestly, I would rather see a new modeling language built from scratch, focused on building systems, that didn’t carry all that requirement/communication/documentation-oriented crap^H^H^H^Hbaggage that UML has (yes, I am talking about you, use case, sequence, instance and collaboration diagrams!), and developed in a more open and agile process than the OMG can possibly do. But I am not hopeful. The current divide between general purpose and domain specific modeling communities is not helping either.

So, what is your opinion? Do you think there are any better alternatives that address the shortcomings of UML without imposing any significant caveats of their own? Have your say.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Myths that give model-driven development a bad name

It seems that people that resist the idea of model-driven development (MDD) do so because they believe no tool can have the level of insight a programmer can. They are totally right about that last part. But that is far from being the point of MDD anyways. However, I think that unfortunate misconception is one of the main reasons MDD hasn’t caught on yet. Because of that, I thought it would be productive to explore this and other myths that give MDD a bad name.

Model-driven development myths

Model-driven development makes programmers redundant. MDD helps with the boring, repetitive work, leaving more time for programmers to focus on the intellectually challenging aspects. Programmers are still needed to model a solution, albeit using a more appropriate level of abstraction. And programmers are still needed to encode implementation strategies in the form of reusable code generation templates or model-driven runtime engines.

Model-driven development enables business analysts to develop software (a variation of the previous myth). The realm of business analysts is the problem space. They usually don’t have the skills required to devise a solution in software. Tools cannot bridge that gap. Unless the mapping between the problem space and solution space is really trivial (but then you wouldn’t want to do that kind of trivial job anyways, right?).

Model-driven development generates an initial version of the code that can be manually maintained from there on. That is not model-driven, it is model-started at most. Most of the benefits of MDD are missed unless models truly drive development.

Model-driven development involves round-trip engineering. In MDD, models are king, 3GL source code is object code, models are the source. The nice abstractions from the model-level map to several different implementation artifacts that capture some specific aspect of the original abstraction, combined with implementation-related aspects. That mapping is not without loss of information, so it is usually not reversible in a practical way, even less so if the codebase is manually maintained (and thus inherently inconsistent/ill-formed). More on this in this older post, pay attention to the comments as well.

Model-driven development is an all or nothing proposition. You use MDD where it is beneficial, combining with manually developed artifacts and components where appropriate. But avoid mixing manual written code with automatically generated code in the same artifact.

What is your opinion? Do you agree these are myths? Any other myths about MDD that give it a bad name that you have seen being thrown around?


Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Interview at

Last December I had the pleasure of being interviewed by Jordi Cabot, the maintainer of, a web site on all things model-driven. We talked mostly about the TextUML Toolkit project, but Jordi also asked about my opinions on more general subjects, such as modeling notations, textual modeling frameworks, DSLs, UML and trends in modeling.

Jordi has recently made a transcription of the interview available on his web site. Take a read, feel free to leave a comment, I am very keen on discussing on any of the topics covered.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Doing away with custom UML metaclasses in TextUML

The TextUML Toolkit has since release 1.2 had a metamodel extension package (inaptly named ‘meta’). This metamodel extension package defined new metaclasses not available in UML such as:

  • closure – an activity that has another activity as context
  • conversion action – an action that flows an input directly as output just changing the type
  • literal double – a literal value for double precision numeric values
  • signature – a classifier that contained parameters, the type of a closure
  • meta value specification – a value specification for meta references
  • collection literals – a value specification that aggregates other value specifications

Turns out extending the UML metamodel by definining new packages and metaclasses is a bad idea. Some reasons (yes, I am feeling ‘bullety’):

  • it is non-standard
  • other UML tools cannot read instances of your metaclasses, some won’t read your models at all if they have *any* unknown metaclasses
  • there is little documentation on how to maintain these kinds of metamodel extensions
  • since it is not the mainstream approach, we are bound to encounter more issues

Because of that, release 1.6 will rely exclusively on profiles and stereotypes for extending the UML metamodel.

What to expect

For conventional users of the Toolkit, this change might possibly go unnoticed, barring any potential bugs introduced in the process.

People using the built-in base package and the base_profile will be directly affected. The elements in these models are still provided, by they are now in the new mdd_extensions profile, or one of the new mdd_types, mdd_collections and mdd_console packages.

We apologize for any inconvenience these changes might bring, but we strongly believe they are required to make the TextUML Toolkit a better product. If you have any trouble moving to 1.6 (to be released later this month), make sure to hit the user forums or report issues.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

TextUML Toolkit 1.5 is out!

Release 1.5 of the TextUML Toolkit is now available from the update sites, for both Eclipse 3.5+ and 3.4. Update or install. We got a few new features in this release.

Content assist
There is now early support for content assist (contributed by Attila Bak), with initial support for stereotype applications.
Content assist in action

Element aliasing
You can now enable aliasing by creating repository properties in the form:


For instance:


New textual notation features
There is now textual notation support for decimal literals.

You might have noticed 1.4 was announced here less than a month ago. We decided to start pushing releases as often as we can, so you can expect a bunch of 1.x releases throughout 2010. If you want to see some feature in the TextUML Toolkit, ask away!

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Can TextUML be implemented the generative way (with Xtext or EMFText)?

I have been trying to figure out whether the TextUML notation for action semantics can be dealt with properly by tools such as Xtext and EMFText (class models and state machines should be fine). For example, given this structural model fragment:

class Advertisement 
    attribute summary : String;
    attribute description : String; 
    attribute keywords : Keyword[*]; 
    attribute category : Category;  
    operation addKeyword(keywordName : String);
    static operation findByCategoryName(catName : String) : Advertisement[*];

association AdvertisementKeyword
    role Advertisement.keywords;
    role advertisement : Advertisement;

class Keyword specializes Object
    attribute name : String;

class Category specializes Object
    attribute name : String;
    attribute description : String;

association AdvertisementCategory
    role Advertisement.category;
    role ad : Advertisement[*];

Notice the Advertisement class declares two operations. Their behaviour in TextUML could be written as:

    operation Advertisement.addKeyword;
        var newKeyword : Keyword; 
        newKeyword := new Keyword; := keywordName;
        link AdvertisementKeyword(keywords := newKeyword, advertisement := self);

    operation Advertisement.findByCategoryName;
        return Advertisement
            (a : Advertisement) : Boolean {
                return a->AdvertisementCategory-> = catName; 

Note that TextUML allows the behavior to be specified inline when declaring an operation in a class, or in separate, as above (that explains the lack of parameters, modifiers etc).

In the resulting UML model, the behaviour of Advertisement.addKeyword would roughly map to this (using a textual pseudo-notation for UML activities that is hopefully more readable than raw XMI):

activity(name: "addKeyword") {
    structuredActivityNode {
        variable(name: "newKeyword", type: #String)
        writeVariable(variable: #newKeyword, value: createObject(class: #Keyword))
            target: readVariable(variable: #newKeyword), 
            value: readVariable(variable: #keywordName)
            association: #AdvertisementKeyword, 
            end1: #AdvertisementKeyword.keyword, 
            end1Value: readVariable(variable: #newKeyword), 
            end2: #AdvertisementKeyword.advertisement, 
            end2Value: readSelf()

and the behaviour Advertisement.findByCategoryName would map to this:

activity(name: "findByCategoryName") {
    structuredActivityNode {
        // implicit variable for return value
        variable(name: "@result", type: #Advertisement, upperBound: *)
        // implicit variable for parameter value
        variable(name: "catName", type: #String)
            variable: #@result, 
            value: callOperation(
                target: readExtent(class: #Advertisement),
                filter: metaValue(#@findByCategoryName_closure1)

// a closure is an activity that has a reference to a context activity
closure(name: "@findByCategoryName_closure1") {
        // implicit variable for return value
        variable(name: "@result", type: #Boolean)
        // implicit variable for parameter value
        variable(name: "a", type: #Advertisement)
            variable: #@result, 
            value: callOperation(
                operation: #Object.equals,
                // variables from the context activity are available here
                target: readVariable(variable: #catName)
                args: readAttribute(attribute:, target: readLink(
                    association: #AdvertisementCategory,
                    fedEndValue: readVariable(variable: #a),
                    readEnd: #Advertisement.category

Note that UML does not have closures, this is an extension to the UML metamodel which I wrote about here before.

Some background on the metaclasses involved: ReadVariableAction, CreateObjectAction, CreateLinkAction, ReadExtentAction etc are all action metaclasses. Actions are the building blocks for modeling activity behaviour in UML.

The million dollar question is: can Xtext and EMFText handle more complex textual notations like this? Is this out of the happy path? Has anyone done something similar? I am under the impression I could use Xtext or EMFText better if I used them based on a intermediate metamodel for behavior that would be closer to the concrete syntax (to get all the IDE bells and whistles for free) and then transformed that to UML in a separate step.

If you have the answers for any of these questions (or even if you have comments and questions of your own), please chime in.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

Eclipse Modeling Day in Toronto

Last Wednesday I attended the Eclipse Modeling Day in Toronto. Coming all the way from Victoria, I must have been the participant that came from farthest. Except, of course, those folks from SAP AG and Itemis that were presenting. But I was really glad to be there. I finally had the chance to chat and discuss about Eclipse and Modeling face to face with people like Simon Kaegi (server-side OSGi), Kenn Hussey (MDT UML2), Eike Stepper (CDO), Ed Merks and (fellow Brazilian) Marcelo Paternostro (EMF), Lynn Gayowski and Ian Skerret (Eclipse Foundation). It’s weird: I have been part of the Eclipse Modeling community since 2006 (and the larger Eclipse community since 2002), but had never actually met any of those folks before. Also amusing was that even though I worked for IBM Ottawa for quite a few years, my first time at the Toronto Lab was many years later as an ex-IBMer living on the West Coast.

The presentations I attended were in general very good. I had seen Ed Merks’ opening presentation on the web before, but this time I could ask questions. I got a better understanding of Xtext (great presentation!), CDO, and the Query, Validation and Transaction frameworks, some technologies I am considering adopting in the near future. I had a first time contact with the Papyrus 2.0 vision, which might provide an opportunity for increasing adoption of the TextUML notation by integrating the TextUML Toolkit into a larger modeling environment. And I liked the idea of a discussion panel at the end.

I had to catch a flight back home that same night, so I could not attend the Eclipse RT Day on the following day nor could I see any of the demos at the DemoCamp. Speaking of which, I did manage to stay long enough to have a beer on the Foundation (thanks!), and chat with Christopher Nagy from Dexterra/Antenna Software, who made a quick ad hoc demo to Ian and myself of their Eclipse/GEF-based tool for authoring multiplatform mobile applications. Very impressive!

As constructive criticism, I do agree with Bjorn that the format could use some tweaking. I sure had to miss some very promising presentations. Maybe with two presentation formats, a longer (for instance, 40-50 mins) and a shorter one (20-25 mins), we wouldn’t need two tracks. I am not sure presenters who came from Europe would have come had they had a shorter slot though. That being said, I was very satisfied with the event overall and am sincerely thankful to IBM Toronto for hosting the event, the Eclipse Foundation for organizing it, all the folks presenting and the companies sponsoring them. Thank you very much! As Lawrence wrote, hope we will see more events like this in the future!

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter