You may have seen our plan for testing code generation before. We are glad to report that that plan has materialized and code generation tests are now supported in AlphaSimple. Follow the steps below for a quick tour over this cool new feature!

Create a project in AlphaSimple

First, you will need a model so you can generate code from. Create a project in AlphaSimple and a simple model.

package person;

enumeration Gender
  Male, Female
end; 

class Person
    attribute name : String;
    attribute gender : Gender;
end;

end.

Enable code generation and automated testing

Create a mdd.properties file in your project to set it up for code generation and automated testing:

# declares the code generation engine
mdd.target.engine=stringtemplate

# imports existing POJO generation template projects
mdd.importedProjects=http://alphasimple.com/mdd/publisher/rafael-800/,http://alphasimple.com/mdd/publisher/rafael-548/

# declares a code generation test suite in the project
mdd.target.my_tests.template=my_tests.stg
mdd.target.my_tests.testing=true

# enables automated tests (model and templates)
mdd.enableTests=true

Write a code generation test suite

A code generation test suite has the form of a template group file (extension .stg) configured as a test template (already done in the mdd.properties above).

Create a template group file named my_tests.stg (because that is the name we declared in mdd.properties), with the following contents:

group my_tests : pojo_struct;

actual_pojo_enumeration(element, elementName = "person::Gender") ::= "<element:pojoEnumeration()>"

expected_pojo_enumeration() ::= <<
enum Gender {
    Male, Female
}
>>

A code generation test case is defined as a pair of templates: one that produces the expected contents, and another that produces the actual contents. Their names must be expected_<name> and actual_<name>. That pair of templates in the test suite above form a test case named “pojo_enumeration”, which unsurprisingly exercises generation of enumerations in Java. pojo_enumeration is a pre-existing template defined in the “Codegen – POJO templates” project, and that is why we have a couple of projects imported in the mdd.properties file, and that is why we declare our template suite as an extension of the pojo_struct template group. In the typical scenario, though, you may would have the templates being tested and the template tests in the same project.

Fix the test failures

If you followed the instructions up to here, you should be seeing a build error like this:

Line	File		Description
3	my_tests.stg	Test "pojo_enumeration" failed: [-public -]enum Gender {\n Male, Female\n}

which is reporting the code generated is not exactly what was expected – the template generated the enumeration with an explicit public modifier, and your test case did not expect that. Turns out that in this case, the generated code is correct, and the test case is actually incorrect. Fix that by ensuring the expected contents also have the public modifier (note that spaces, newlines and tabs are significant and can cause a test to fail). Save and notice how the build failure goes away.

That is it!

That simple. We built this feature because otherwise crafting templates that can generate code from executable models is really hard to get right. We live by it, and hope you like it too. That is how we got the spanking new version of the POJO target platform to work (see post describing it and the actual project) – we actually wrote the test cases first before writing the templates, and wrote new test cases whenever we found a bug – in the true spirit of test-driven code generation.

• Person class
• Account class

This is all live in AlphaSimple – every time you hit those URLs the code is being regenerated on the fly. If you are curious, the UML model is available in full in the TextUML’s textual notation, as well as in the conventional graphical notation. For looking at the entire project, including the code generation templates, check out the corresponding AlphaSimple project.

Preconditions

Operation preconditions impose rules on the target object state or the invocation parameters. For instance, for making a deposit, the amount must be a positive value:

operation deposit(amount : Double);
precondition (amount) { return amount > 0 }
begin
    ...
end;

which in Java could materialize like this:

public void deposit(Double amount) {
    assert amount > 0;
    ...
}

Not related to preconditions, another case assertions can be automatically generated is if a property is required (lowerBound > 0):

public void setNumber(String number) {
    assert number != null;
    ...
}

Imperative behavior

In order to achieve 100% code generation, models must specify not only structural aspects, but also behavior (i.e. they must be executable). For example, the massAdjust class operation in the model is defined like this:

static operation massAdjust(rate : Double);
begin
    Account extent.forEach((a : Account) {
        a.deposit(a.balance*rate)
    });
end;

which in Java results in code like this:

public static void massAdjust(Double rate) {
    for (Account a : Account.allInstances()) {
        a.deposit(a.getBalance() * rate);
    };
}

Derived properties

Another important need for full code generation is proper support for derived properties (a.k.a. calculated fields). For example, see the Account.inGoodStanding derived attribute below:

derived attribute inGoodStanding : Boolean := () : Boolean {
    return self.balance >= 0
};

which results in the following Java code:

public Boolean isInGoodStanding() {
    return this.getBalance() >= 0;
}

Set processing with higher-order functions

Any information management application will require a lot of manipulation of sets of objects. Such sets originate from class extents (akin to “#allInstances” for you Smalltalk heads) or association traversals. For that, TextUML supports the higher-order functions select (filter), collect (map) and reduce (fold), in addition to forEach already shown earlier. For example, the following method returns the best customers, or customers with account balances above a threshold:

static operation bestCustomers(threshold : Double) : Person[*];
begin
    return
        (Account extent
            .select((a:Account) : Boolean { return a.balance >= threshold })
            .collect((a:Account) : Person { return a->owner }) as Person);
end;

which even though Java does not yet support higher-order functions, results in the following code:

public static Set<Person> bestCustomers(Double threshold) {
    Set<Person> result = new HashSet<Person>();
    for (Account a : Account.allInstances()) {
        if (a.getBalance() >= threshold) {
            Person mapped = a.getOwner();
            result.add(mapped);
        }
    }
    return result;
}

which demonstrates the power of select and collect. For an example of reduce, look no further than the Person.totalWorth attribute:

derived attribute totalWorth : Double := () : Double {
    return (self<-PersonAccounts->accounts.reduce(
        (a : Account, partial : Double) : Double { return partial + a.balance }, 0
    ) as Double);
};

which (hopefully unsurprisingly) maps to the following Java code:

public Double getTotalWorth() {
    Double partial;
    partial = 0;
    for (Account a : this.getAccounts()) {
        partial = partial + a.getBalance();
    }
    return partial;
}

Would you hire AlphaSimple?

Would you hire a developer if they wrote Java code like AlphaSimple produces? For one thing, you can’t complain about the guy not being consistent. Do you think the code AlphaSimple produces needs improvement? Where?

Want to try by yourself?

There are still some bugs in the code generation that we need to fix, but overall the “POJO” target platform is working quite well. If you would like to try by yourself, create an account in AlphaSimple and to make things easier, clone a public project that has code generation enabled (like the “AlphaSimple” project).

And here they are again for the sake of searchability:

I – Enterprise Software is much harder than it should be, lack of separation of concerns is to blame.

II – Domain and architectural/implementation concerns are completely different beasts and should be addressed separately and differently.

III – What makes a language good for implementation makes it suboptimal for modeling, and vice-versa.

IV – Domain concerns can and should be fully addressed during modeling, implementation should be a trivial mapping.

V – A model that fully addresses domain concerns will expose gaps in requirements much earlier.

VI – A model that fully addresses domain concerns allows the solution to be validated much earlier.

VII – No modeling language is more understandable to end-users than a running application (or prototype).

VIII – A single architecture can potentially serve applications of completely unrelated domains.

IX – A same application can potentially be implemented according to many different architectures.

X – Implementation decisions are based on known guidelines applied consistently throughout the application, and beg for automation.

XI – The target platform should not dictate the development tools, and vice-versa.

I truly believe in those principles, and feel frustrated when I realize how far the software industry is from abiding by them.

So, what do you think? Do you agree these are important principles and values? Would you call B.S. on any of them? What are your principles and values that drive your vision of what software development should look like?

One way to perform early validation is to automatically generate a prototype that non-technical stakeholders can play with and (manually) confirm the proposed model does indeed satisfy their needs (like this).

Another less obvious way to benefit from executable models since day one is automated testing.

The requirements

For instance, let’s consider an application that needs to deal with money sums:

• REQ1: a money sum is associated with a currency
• REQ2: you can add or subtract two money sums
• REQ3: you can convert a money sum to another currency given an exchange rate
• REQ4: you cannot combine money sums with different currencies

The solution

A possible solution for the requirements above could look like this (in TextUML):

package money;

class MixedCurrency
end;

class Money
  attribute amount : Double;
  attribute currency : String;

  static operation make(amount : Double, currency : String) : Money;
  begin
      var m : Money;
      m := new Money;
      m.amount := amount;
      m.currency := currency;
      return m;
  end;

  operation add(another : Money) : Money;
  precondition (another) raises MixedCurrency { return self.currency = another.currency }
  begin
      return Money#make(self.amount + another.amount, self.currency);
  end;

  operation subtract(another : Money) : Money;
  precondition (another) raises MixedCurrency { return self.currency = another.currency }
  begin
      return Money#make(self.amount - another.amount, self.currency);
  end;

  operation convert(anotherCurrency : String, exchangeRate : Double) : Money;
  begin
      return Money#make(self.amount * exchangeRate, anotherCurrency);
  end;
end;

end.

Now, did we get it right? I think so, but don’t take my word for it.

The proof

Let’s start from the beginning, and ensure we satisfy REQ1 (a money sum is a pair <amount, currency>:

[Test]
operation testBasic();
begin
    var m1 : Money;
    m1 := Money#make(12, "CHF");
    Assert#assertEquals(12, m1.amount);
    Assert#assertEquals("CHF", m1.currency);
end;

It can’t get any simpler. This test shows that you create a money object providing an amount and a currency.

Now let’s get to REQ2, which is more elaborate – you can add and subtract two money sums:

[Test]
operation testSimpleAddAndSubtract();
begin
    var m1 : Money, m2 : Money, m3 : Money, m4 : Money;
    m1 := Money#make(12, "CHF");
    m2 := Money#make(14, "CHF");

    m3 := m1.add(m2);
    Assert#assertEquals(26, m3.amount);
    Assert#assertEquals("CHF", m3.currency);

    /* if m1 + m2 = m3, then m3 - m2 = m1 */
    m4 := m3.subtract(m2);
    Assert#assertEquals(m1.amount, m4.amount);
    Assert#assertEquals(m1.currency, m4.currency);
end;

We add two values, check the result, them subtract one of them from the result and expect the get the other.

REQ3 is simple as well, and specifies how amounts can be converted across currencies:

[Test]
operation testConversion();
begin
    var m1 : Money, result : Money;
    m1 := Money#make(3, "CHF");
    result := m1.convert("USD", 2.5);
    Assert#assertEquals(7.5, result.amount);
    Assert#assertEquals("USD", result.currency);
end;

We ensure conversion generates a Money object with the right amount and the expected currency.

Finally, REQ4 is not a feature, but a constraint (currencies cannot be mixed), so we need to test for rule violations:

[Test]
operation testMixedCurrency();
begin
    try
        Money#make(12, "CHF").add(Money#make(14, "USD"));
        /* fail, should never get here */
        Assert#fail("should have failed");
    catch (expected : MixedCurrency)
        /* success */
    end;
end;

We expect the operation to fail due to a violation of a business rule. The business rule is identified by an object of a proper exception type.

There you go. Because we are using executable models, even before we decided what implementation platform we want to target, we already have a solution in which we have a high level of confidence that it addresses the domain-centric functional requirements for the application to be developed.

Can you say “Test-driven modeling”?

Imagine you could encode all non-technical functional requirements for the system in the form of acceptance tests. The tests will run against your models whenever a change (to model or test) occurs. Following the Test-Driven Development approach, you alternate between encoding the next requirement as a test case and enhancing the model to address the latest test added.

Whenever requirements change, you change the corresponding test and you can easily tell how the model must be modified to satisfy the new requirements. If you want to know why some aspect of the solution is the way it is, you change the model and see the affected tests fail. There is your requirement traceability right there.

See it by yourself

Would you like to give the mix of executable modeling and test-driven development a try? Sign up to AlphaSimple now, then open the public project repository and clone the “Test Infected” project (or just view it here).

P.S.: does this example model look familiar? It should – it was borrowed from “Test Infected: Programmers Love Writing Tests“, the classical introduction to unit testing, courtesy of Beck, Gamma et al.

Back-of-a-napkin design for code generation testing:

1. by convention, for each test case, declare two transformations: one will hardcode the expected results, and another will trigger the transformation to test with some set of parameters (typically, an element of a model). We can pair transformations based on their names: “expected_foo” and “actual_foo” for a test case named “foo”
2. if the results are identical, the test passes; otherwise, the test fails (optionally, use a warning for the cases where the only differences are around layout, i.e., non significant chars like spaces/newlines – optionally, because people generating Python code will care about layout)
3. just as we do for model test failures, report template test failures as build errors
4. run template tests after model tests, and only if those pass
5. (cherry on top) report text differences in a sane way (some libraries out there can do text diff’ng)

Does that make sense? Any suggestions/comments (simpler is better)? Have you done or seen anything similar?

• Analysis deals with understanding the problem domain and requirements in detail
• Design deals with actually addressing those (functional and non-functional) requirements
• A detailed design model can be automatically transformed into a working implementation
• An analysis model can’t, as in the general case, it is not possible to automatically derive a solution based on the statement of a problem.

Rumbaugh, Blaha et al in “Object-oriented modeling and design” (one of the first OO modeling books) state the purpose of analysis in OO is to model the real-world system so it can be understood; and the outcome of analysis is understanding the problem in preparation for design.

Jacobson, Booch and Rumbaugh (again, now with the other “two amigos”) in “The unified software development process” state that “an analysis model yields a more precise specification of the requirements than we have in the results from requirements capture” and “before one starts to design and implement, one should have a precise and detailed understanding of the requirements”.

Ok, so I thought I was in good company there. However, while reading the excellent “Model-based development: applications“, to my great surprise, H. S. Lahman clearly states that contrary to structured development, where the focus of analysis is problem analysis, in the object-oriented paradigm, problem analysis is done during requirements elicitation, and the goal of object-oriented analysis is to specify the solution in terms of the problem space, addressing functional requirements only, in a way that is independent of the actual computing environment. Also, Lahman states that the OOA model is the same as the platform-independent model (PIM) in MDA lingo, so it can actually be automatically translated into running code.

That is the first time I have seen this position defended by an expert. I am not familiar with the Shlaer-Mellor method, but I won’t be surprised if it has a similar view of analysis, given that Lahman’s method is derived from Shlaer-Mellor. Incidentally, Mellor/Balcer’s “Executable UML: a foundation for model-driven architecture” is not the least concerned with the software lifecycle, briefly mentions use cases as a way of textually gathering requirements, and focuses heavily on solution modeling.

My suspicion is that for the Shlaer-Mellor/Executable UML camp, since models are fully executable, one can start solving the problem (in a way that is removed from the actual concrete implementation) since the very beginning, so there is nothing to be gained by strictly separating problem from a high-level, problem-space focused solution. Of course, other aspects of the solution, concerned with non-functional requirements or somehow tied with the target computing environment, are still left to be addressed during design.

And now I see how that all makes sense – I struggled myself with how to name what you are doing when you model a solution in AlphaSimple. We have been calling it design based on the more traditional view of analysis vs. design – since AlphaSimple models specify a (highly abstract) solution, it couldn’t be analysis. But now I think I understand: for approaches based on executable modeling, the divide between understanding the problem and specifying a high-level solution is so narrow and so cheap to cross, that both activities can and should be brought closer together, and the result of analysis in approaches based on executable modeling is indeed a model that is ready to be translated automatically into a running application (and can be quickly validated by the customer).

But for everybody else (which is the vast majority of software development practitioners – executable modeling is still not well known and seldom practiced) that is just not true, and the classical interpretation still applies: there is value in thoroughly understanding the requirements before building a solution, given that the turnaround between problem comprehension, solution building and validation is so damn expensive.

For those of you thinking that this smells of BigDesignUpFront, and that is not an issue with agile or iterative approaches in general – I disagree. At least as far as typical iterative approaches go, where iterations need to comprise all/several phases of the software development life cycle so they can finally deliver results that can be validated by non-technical stakeholders. As such they are still very wasteful (the use of the word agile feels like a bad joke to me).

Approaches based on executable modeling, on the other hand, greatly shrink the chasm between problem analysis and conceptual solution modeling and user acceptance, allowing for much more efficient and seamless collaboration between the problem domain expert and the solution expert. Iterations become so action packed that they are hardly discernible. Instead of iterations taking weeks to allow for customer feedback, and a project taking months to fully cover all functional requirements, you may get a fully specified solution after locking a customer and a modeler in a boardroom for just a day, or maybe a week for bigger projects.

So, long story short, to answer the question posed at the beginning of this post, the answer is both, but only if you are following an approach based on executable modeling.

What is your view? Do you agree with that? Are you an executable modeling believer or skeptic?

UPDATE: make sure to check the thread on Google+ as well.

The plan is to take the audience from the most basic ideas around generating code from models, visiting approaches increasingly more sophisticated, analyzing their pros and cons, all the way to full code generation based on executable models.

In the process, we will be taking a cursory look at some code generation tools in the market, culminating with a preview of the upcoming release of AlphaSimple, our online modeling tool, which will support executable modeling and full code generation.

What:

May 2011 VIJUG Meeting – Code generation: going all the way (official announcement)

Where:

Vancouver Island Technology Park, Conference Center Room – 4464 Markham Street, Victoria, BC

When:

Thursday, 26th May 2011, 18:00-20:00

If you are in Victoria and think developing business applications got just way too complicated and labor-intensive, and that there must be a saner way to build and evolve them (no matter what platforms you use), come to this presentation and learn how executable models and full code generation can fix that.

Here are some examples of how to translate from closure-based loops (in TextUML, but the specific syntax shouldn’t matter) to ordinary loops (in Java, but again, syntax specifics shouldn’t matter):

forEach

In TextUML

self->units.forEach((u : Unit) {
    link ProjectUnits(project := clone, units := u.clone()) }
);

In Java

for (Unit u : this.getUnits()) {
    clone.addUnits(u.clone());
}

select

In TextUML

return Project extent.select((p : Project) : Boolean { return p.shared });

In Java

Set<Project> result = new HashSet<Project>();
for (Project p : Project.allInstances()) {
    if (p.isShared()) {
        result.add(p);
    }
}
return result;

collect

In TextUML

return Project extent.collect((p : Project) : User { return p->owner });

In Java

Set<User> result = new HashSet<User>();
for (Project p : Project.allInstances()) {
    User owner = p.getOwner();
    result.add(owner);
}
return result;

count

In TextUML

return Project extent.count((p : Project) : Boolean { return p.shared });

In Java

int count = 0;
for (Project p : Project.allInstances()) {
    if (p.isShared()) {
        count++;
    }
}
return count;

In AlphaSimple, we got much of what is needed above in place. There are though some additional challenges posed by the need of chaining those collection primitives, and the need for mapping the data flow that chains them together to an unchained form, using local variables in the target language. These last two aspects have been keeping me awake at night. If you feel like throwing a light (with strategies, references) on how to address that, by all means go for it, it is pretty dark in here right now…

Does this 7-slide pitch deck (including title) help you understand it?

If not, please let us know. Or if it is clear, but you don’t think it would work, please help us understand why. Or even if you think it is right on the money, some reassurance is always welcome.

Note that the web site hasn’t yet changed to reflect the more recent focus on code generation that the slide deck hints at (in addition to the existing focus on requirements and solution design validation). That is on our to-do list. Expect significant changes (messaging and service features) this Spring.

This is the inaugural post on the “business of software” category. Expect many more in the future as we work on turning AlphaSimple into a product that fulfills our mission: to bring model-driven development to the masses, and stopping hordes of developers from writing so much code. Stay tuned.

O número de participantes foi bastante pequeno (14 respostas), o que limita bastante a significância estatística dos dados obtidos. De qualquer forma, há valor em analisar essa pequena amostra qualitativamente.

Resultados da pesquisa

Esta primeira pergunta serviu apenas para fornecer contexto para qualificar as respostas seguintes. Por exemplo, para ajudar a identificar que tecnologias de implementação são mais frequentemente associadas com geração de código. Como já era esperado, fica claro o domínio de Java (como linguagem ou plataforma) e .Net (tanto C# como VB.net). Destaque para as presenças de COBOL (!), Visual Dataflex e Apex (os dois últimos aparentemente como única linguagem na empresa).

Enterprise Architect claramente lidera como linguagem de modelagem (6 dos 11 que usam alguma ferramenta), seguido pelos suites Rational da IBM (entrevistados mencionaram Rose e RSA), e pelo Jude/Astah* da japonesa Change Vision. Duas ferramentas de criação de diagramas que executam no browser foram mencionadas: Create.ly e yUML.me.

Entre os entrevistados que usam modelagem (11 de 14), todos disseram que comunicação com desenvolvedores era uma finalidade primária. 63% dos que modelam (7 de 11) também usam modelos para comunicação com clientes. Apenas quatro entrevistados identificaram geração de código como finalidade primária.

Para aqueles que disseram não modelar (3), coincidência ou não, dois usam 4GLs como linguagem primária – 4GLs fornecem muitos dos benefícios de modelagem e geração de código, então o ROI não é tão claro quanto para quem usa 3GLs. Contraste isso com o fato que dos 4 entrevistados que vêem geração de código como finalidade primária, todos têm Java ou .Net (C#, VB.Net) como linguagem/plataforma.

Esta pergunta requeria um motivo caso a equipe não modelasse ou não gerasse código a partir de modelos. Razões mencionadas (apenas por aqueles que modelam):

• modelar é caro, e o time já sabe escrever código, então não há valor suficiente
• modelos não são detalhados o suficiente para se gerar código
• código gerado não iria satisfazer as necessidades do time
• várias ferramentas testadas, nenhuma satisfez as necessidades
• não há tempo (para se modelar a ponto de se gerar código?)

Mesmo que geração de código não seja uma finalidade primária para a maioria dos que modelam, metade dos entrevistados responderam que usam alguma ferramenta de geração de código, o que inclui frameworks que suportam scaffolding (Django) e IDEs/wizards. Isso revela a percepção de que geração de código tem importância limitada no desenvolvimento, e o quão variado é o rol de ferramentas identificadas como geradores de código. Também revela um problema na questão por não qualificar “geração de código” como sendo especificamente a partir de modelos (o que excluiria wizards em IDEs).

Entre aqueles que geram código, mais da metade dos entrevistados usa ferramentas que gera apenas métodos vazios (stubs), o que corrobora com a visão de que geração de código não oferece valor suficiente. Ferramentas que só ajudam o programador no “pontapé inicial” têm valor limitado quando se considera custos com manutenção e evolução são boa parte do custo em software.

Note que entre os entrevistados que geram código (7), quase todos usam geração de código apenas como ponto de partida. Apenas um entrevistado declarou regerar o código após mudanças no modelo, e modificações existentes são preservadas via regiões protegidas. Os outros (6/7) ou replicam modificações no modelo e no código manualmente (2/7), ou abandonam o modelo e fazem modificações diretamente no código (4/7). Nenhum dos entrevistados usam técnicas como o padrão generation gap para combinar código gerado com código escrito manualmente.

Conclusão

Mesmo que o tamanho da amostra não seja grande o suficiente para se fazer conclusões definitivas, acho que as respostas obtidas confirmam fortemente algumas suspeitas que tínhamos:

1. geração de código é pouco utilizada
2. quando utilizada, a capacidade em que é utilizada não produz valor significativo em um projeto
3. desenvolvimento baseado em modelos (MDD) é ainda raramente praticado (1 em 14)

O que você acha? Concorda com as conclusões? Tem conclusões próprias para contribuir?

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?

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.

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 ...>
...
<pluginRepositories>
...
  <pluginRepository>
    <id>abstratt</id>
    <name>Abstratt Technologies Maven repository</name>
    <url>http://abstratt.com/maven/</url>
  </pluginRepository>
...
</pluginRepositories>
...
<project>

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 ...>
...
<build>
...
<plugins>
...
  <plugin>
    <groupId>com.abstratt</groupId>
    <artifactId>com.abstratt.alphasimple.mojo</artifactId>
    <version>1.0-SNAPSHOT</version>
    <configuration>
      <uri>http://alphasimple.com/mdd/generator/rafael-276/simple</uri>
      <targetRoot>${project.build.directory}/generated-src/main/java</targetRoot>
    </configuration>
    <executions>
      <execution>
        <phase>generate-sources</phase>
        <goals>
          <goal>generate</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
...
</plugins>
...
</build>
...
</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 http://alphasimple.com/mdd/generator/rafael-276/simple, 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 ...>
...
<build>
  ...
  <sourceDirectory>${project.build.directory}/generated-src/main/java</sourceDirectory>
  ...
</build>
...
</project>

Step 3: run Maven

    mvn clean generate-sources

will get you something like this:

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building AlphaSimple Code Generation example 0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ com.alphasimple.examples.pojo ---
[INFO] Deleting file set: C:\dev\com.alphasimple.examples.pojo\target (included: [**], excluded: [])
[INFO]
[INFO] --- com.abstratt.alphasimple.mojo:1.0-SNAPSHOT:generate (default) @ com.alphasimple.examples.pojo ---
[INFO] Generating at C:\dev\com.alphasimple.examples.pojo\target\generated-src\main\java\alphasimple\Project.java
[INFO] Generating at C:\dev\com.alphasimple.examples.pojo\target\generated-src\main\java\alphasimple\Session.java
[INFO] Generating at C:\dev\com.alphasimple.examples.pojo\target\generated-src\main\java\alphasimple\Unit.java
[INFO] Generating at C:\dev\com.alphasimple.examples.pojo\target\generated-src\main\java\alphasimple\User.java
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[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.

Conclusion
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!

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();
    begin
        self.check := not self.check;
    end;
    /* queries */
end;

end.

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) !>
<class.name>.txt
>>

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

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

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

Again, remember to save this file.

Declare your custom template

To enable custom templates, you need to create an AlphaSimple configuration file (mdd.properties). 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
mdd.target.engine=stringtemplate

# the templates supported (always mdd.target.<name>.template=<template file name>
mdd.target.simple.template=simple.stg

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:

http://alphasimple.com/mdd/publisher/<username>-<project-id>/

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

http://alphasimple.com/mdd/publisher/simple-515/

which returns:

<workspace packageCount='1' timestamp='1298449947000'>
  <model name='NewProject.uml'
    uri='http://alphasimple.com/mdd/publisher/simple-515/NewProject.uml?secret='
    graph='http://alphasimple.com/mdd/diagram/simple-515/NewProject.uml?secret='/>
  <properties name='mdd.properties' uri='http://alphasimple.com/mdd/publisher/simple-515/mdd.properties?secret='/>
  <source name='NewProject' uri='http://alphasimple.com/mdd/publisher/simple-515/NewProject?secret='/>
  <source name='simple.stg' uri='http://alphasimple.com/mdd/publisher/simple-515/simple.stg?secret='/>
  <generator platform="jpa" uri="http://alphasimple.com/mdd/generator/simple-515/jpa?secret="/>
  <generator platform="pojo" uri="http://alphasimple.com/mdd/generator/simple-515/pojo?secret="/>
  <generator platform="simple" uri="http://alphasimple.com/mdd/generator/simple-515/simple?secret="/>
  <renderer uri="http://alphasimple.com/animator/index.jsp?repository=simple-515#"/>
</workspace>

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

Conclusion

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.

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.

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?

• the test area is rebuilt from scratch every time you save your project. When you hit the “Test” button, the prototype you are running is generated based on the test model area. It reflects your latest changes (at the time you hit Test). The URL for the prototype based off of the test area has a “run” segment (http://alphasimple.com/project/run/<id>).
• the published area is only refreshed when you hit Publish. In order to run the prototype off of the published area, you hit “View Published”. Any changes you make to your model will *not* affect the published model/prototype. The URL for the prototype based off of the published area has a “published” segment (http://alphasimple.com/project/published/<id>).

Imagine the published area as a snapshot of your work that you would want others (business analysts, customers, other modelers) to see, while the test area is what you use for your own testing on an ongoing basis as you develop your model. Guest (non-registered) users just quickly trying AlphaSimple anonymously have only the test area.

Shared projects

A mostly orthogonal concept is shared projects. A project that is shared appears in the Shared Projects page in AlphaSimple, and anyone can run the prototype, browse your model (including a graphical view), and even copy your project and make it their own. Any registered user can share their projects. In fact, there is currently a limit of 3 non-shared projects. As you can guess, we want to encourage users to share their models.

You may be asking: “what is the relationship between shared projects and working areas?”. It is simple: what you see when looking at a shared project is the published state of that project. So for a shared project of yours, if you want to affect what is seen on the shared projects page, you need to publish your model (in addition to sharing the project). Actually, there is a bug in that if you don’t ever publish a shared project, trying to run or view it from the Shared Projects page will fail (we should be automatically publishing the model when a project is first shared, or hide shared projects until they are effectively published).

Does all this make sense? Let us know if it doesn’t, either by commenting here or by starting a thread on the community forum.

• 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:

org.eclipse.uml2.uml/src/org/eclipse/uml2/uml/internal/impl/ElementImpl.java

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

org.eclipse.uml2.uml/src/org/eclipse/uml2/uml/util/UMLUtil.java

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

org.eclipse.uml2/plugins/org.eclipse.uml2.common/src/org/eclipse/uml2/common/util/CacheAdapter.java

retrieving revision 1.26
diff -r1.26 CacheAdapter.java
119,120d118
< 	public static final CacheAdapter INSTANCE = createCacheAdapter();
<
537a536,546
> 	//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.

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?

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?

1. sign up for AlphaSimple (it’s free)
2. create a project
3. create your models using the TextUML notation (tutorial, reference). Make sure you use no extension or use .tuml as file extension.
4. once your project is valid, publish it
5. back to your project list (“My Projects”), share the project by clicking the open lock button. Note that when you do that you make your project available for any users to see and copy.
6. now on the shared project list (“Shared Projects”), find and open your project – you will see a “Model Diagram” tab – there is your diagram! If you want to share your diagram with others, you can copy the image location and pass that URL around.

Here is an example of diagram produced for project “Lesson #5 – All together now“:

How does it work?

If you are interested in understanding what is involved here:

1. AlphaSimple uses the TextUML compiler from our open source TextUML Toolkit project translating TextUML source files into UML models (using the Eclipse UML2 format).
2. AlphaSimple also uses the TextUML Toolkit component (based on the EclipseGraphviz project) for generating Graphviz dot diagrams from UML models.
3. For rendering the actual diagram from the dot description, instead of directly using Graphviz, AlphaSimple uses Google’s Chart API support for rendering dot diagrams.

This is all very new, so there may be some rough spots. If you have any issues, or have suggestions, send them our way.

The first feature is editor tabs:

With editor tabs, you get the entire browser window width for your source files, which in the past would have required you to collapse the file list (and lose context of what other files exist in the project).

The second feature is rendering of class diagrams:

Rendering of models as class diagrams provides yet another view into your model, in addition to the textual notation and the prototype. This feature needs more work but we wanted to get it out quick even if not fully baked to get some early feedback.

We hope you like it. Either way, we are eager to hear your opinion.

]]> http://abstratt.com/blog/2010/12/17/new-features-editor-tabs-and-class-diagrams/feed/ 1 http://abstratt.com/blog/2010/11/21/on-model-to-model-transformations/ http://abstratt.com/blog/2010/11/21/on-model-to-model-transformations/#comments Sun, 21 Nov 2010 18:04:32 +0000 rafael.chaves http://abstratt.com/blog/?p=176 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.

It is now much easier to learn how a model relates to the prototype. If you are logged in, and you like a project, you can clone it and start working on your own version right away. Try now!

you get:

<workspace packageCount='1' timestamp='1280186896000'>
  <model name='expenses.uml'
    uri='http://alphasimple.com/mdd/publisher/rafael-26/expenses.uml'
    graph='http://alphasimple.com/mdd/diagram/rafael-26/expenses.uml'/>
  <properties name='mdd.properties'
    uri='http://alphasimple.com/mdd/publisher/rafael-26/mdd.properties'/>
  <source name='expenses'
    uri='http://alphasimple.com/mdd/publisher/rafael-26/expenses'/>
  <renderer
    uri="http://alphasimple.com/animator/index.jsp?repository=rafael-26#"/>
</workspace>

The “model” elements give you access to the models in the project in compiled form (XMI). UPDATE (2010/09/02): model elements now also provide access to the corresponding class diagram (PNG).UPDATE (2011/07/07): model elements now also provide access to the code generation target platforms (such as POJO).

The “source” elements give you access to the source files in the project (currently in TextUML).

The goal is to allow 3rd-parties to access those models, for generating code, rendering diagrams, versioning contents, or whatever crazy idea one can think of. Note that this feature is still experimental and is being made available so people can provide feedback, the specifics might (and probably will) change.

Sign up now and let us know what you think.

There are also some improvements for IE although we still recommend using Firefox, Chrome or Safari.

Go ahead, try it out and tell us what you think!

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?

Take a look at the new notation features:

• preconditions on operations

operation withdraw(amount : Real);
precondition { amount > 0 and amount < self.balance }
begin
    self.balance := self.balance - amount;
end;

• 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!

http://abstratt.com/update

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.

Don’t know what AlphaSimple is?

AlphaSimple is an environment for rapid prototyping. You compose your domain model using an in-browser editor. The model is automatically validated every time you save. Play with your prototype right away. Rinse. Repeat.

AlphaSimple is an online tool for collaborative creation. Once you are happy with your prototype, publish it and send the URI to clients, team members, anyone you would like to see it no matter where they are.

AlphaSimple is a place for sharing. Feeling proud of your work? Share your projects for others in the community to learn from you. It’s just a button away.

AlphaSimple is a place for learning. Don’t know where to start? Browse the catalog of public projects, play with a prototype, and clone it to make it your own. No easier way to learn. If you still need help, the AlphaSimple community forum is there for you (and there is some documentation too).

What are you waiting for?

Take AlphaSimple for a spin. If you are unsure about signing up, try it as a guest. Except for sharing/publishing projects, guest sessions are full-featured.

UPDATE on browser compatibility: the browsers we have been testing on are Chrome and Firefox. Syntax highlighting is broken on Safari, so it has been turned off by default (you can turn it back on). AlphaSimple does not work on Internet Explorer at this time. Flash is required for running prototypes.

It should not take long now. Bear with us, we don’t think you will be disappointed.

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

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?

Rafael

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.

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

mdd.aliases.<source-qualified-name>=<target-qualified-name>

For instance:

mdd.aliases.base\:\:Real=mypackage\:\:MyReal

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!

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

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

class Keyword specializes Object
    attribute name : String;
end;

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

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

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

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

    operation Advertisement.findByCategoryName;
    begin
        return Advertisement extent.select(
            (a : Advertisement) : Boolean {
                return a->AdvertisementCategory->category.name = catName;
            }
        );
    end;

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))
        writeAttribute(
            attribute: #Keyword.name,
            target: readVariable(variable: #newKeyword),
            value: readVariable(variable: #keywordName)
        )
        createLink(
            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)
        writeVariable(
            variable: #@result,
            value: callOperation(
                operation: #Advertisement.select,
                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)
        writeVariable(
            variable: #@result,
            value: callOperation(
                operation: #Object.equals,
                // variables from the context activity are available here
                target: readVariable(variable: #catName)
                args: readAttribute(attribute: #Category.name, target: readLink(
                    association: #AdvertisementCategory,
                    fedEnd: #Advertisement.ad,
                    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.

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!

This is mostly a bug fix release. However, there were some minor notation changes to support stereotypes on dependencies, generalizations and interface realizations, hence the version change from 1.3.x to 1.4.x.

Thanks to Vladimir Sosnin, Attila Bak and fredlaviale for contributing with code and/or bug reports/feature requests. Keep them coming!

As usual, you can find a summary of the changes in the TextUML Toolkit Features page. If you are using the Toolkit, make sure you upgrade soon. If not, what are you waiting for? Install it already!

For the benefit of those not there, here is a web-version of that presentation, with notes showing on the slides (click here for a full screen view).

Comments are very welcome. I would be very happy to discuss the approach with anyone interested.

AlphaSimple is our upcoming web-based service that renders functional prototypes straight from rich domain models. The goal is to bridge the gap between design and requirement analysis, creating a fast feedback loop between those two activities. The result is much more precise and complete requirements early in the project lifecycle, and a sound design model that not only will be a breeze to implement, but that even your customers will understand.

We are craving feedback. If you want to take an alpha version for a spin, sign up at alphasimple.com.

Cheers,

Rafael

http://abstratt.com/update/ – if you are using Eclipse Galileo, or

http://abstratt.com/update/3.4/ – if you are using Eclipse Ganymede.

Please see the feature page for a summary of the evolution of the TextUML Toolkit in terms of features across releases. Some highlights for this release are better integration with other UML tools and support for both Eclipse 3.4 and 3.5.

As usual, bug reports and feature requests are much appreciated. And if you need help, make sure to ask on the user forum.

The TextUML Toolkit Team

Please give it a try and report any issues you might find. If no serious problems are found with this build, it will be promoted to 1.3 final later this week.

Note that the main update site supports Eclipse 3.5, but there is also an update site for Eclipse 3.4.  The features are the same, the only differences between the two sites are the dependencies (UML2 3.0 and EMF 2.5 on Eclipse 3.5, UML2 2.2 and EMF 2.4 on Eclipse 3.4).

The TextUML Toolkit team welcomes your feedback.

More hands on deck

Vladimir Sosnin has joined the project and has been on a roll contributing many patches, not only bug fixes but design improvements and features too. It is amazing how quickly he has become very comfortable with the TextUML Toolkit code base (Vladimir is certainly a solid developer, but I’d like to think the quality of the code base helped him too). And if that was not good enough, Vladimir is also using the TextUML Toolkit in his daily work around model-driven development, so that should help ensuring the Toolkit has the features its target audience actually needs.

New release in the making

1.3RC1 should be made available during the weekend. It has some shiny new language features, a bunch of bug fixes, better integration with other UML2 tools and support for both Galileo and Ganymede. By the way, shipping code that can handle different incompatible versions of Eclipse has become a little more challenging with P2, as you cannot ship a feature that has bundles that resolve in a mutually exclusive way – it seems you really need two different features for that.

Documentation moved to SourceForge

SourceForge now has support for MediaWiki, which is used to author and serve the documentation for the TextUML Toolkit. In the spirit of strengthening the message that the project should really be considered a community-based effort, I decided to migrate the documentation from the Abstratt web site over to SourceForge.

I guess that does it, at least for now.  Stay tuned.

The idea that gave title to Harry’s post is that whenever we use a simpler representation to build something that is more complex and detailed than we want to care about, we are creating models. 3GL source code is a model for object code. Byte code is a model for actual CPU-specific executable code. Hence code is model.

He then goes to ask that if we have been successfully reaping the benefits of increased levels of abstraction by using 3GLs for decades now, what prevents us from taking the next step and using even higher level (modeling) languages? He makes several good points that are at the very foundations of true model-driven development:

• “models must be precise“- models must be amenable to automatic transformation. Models that cannot be transformed into running code are “useless as development artifacts“. If you like them for conceiving or communicating ideas, that is fine, but those belong to a totally different category, one that plays a very marginal role in software development, and have nothing to do with model-driven development. Models created using the TextUML Toolkit are forcefully precise, and can include behavior in addition to structure.
• “models must be intrinsic to the development process” – models need to be “first class citizens of the development process” or they will become irrelevant. That means: everything that makes sense to be modeled is modeled, and running code is generated from models without further manual elaboration, i.e., no manually changing generated code and taking it from there. As a rule, you should refrain from reading generated code or limit yourself to reading the API of the code, unless you are investigating a code generation bug. There is nothing really interesting to see there – that is the very reason why you wanted to generate it in the first place. Build, read, and evolve your models! Generated code is object code.
• “models aren’t always graphical” – of course not. I have written about that before here. The TextUML Toolkit is only one of many initiatives that promote textual notations for modeling (and I mean modeling, not diagramming – see next point).
• “explicitly call out models vs. views” – in other words, always keep in mind that diagrams != models. Models are the real thing, diagrams are just views into them. Models can admit an infinite number of notations, be them graphical, textual, tabular etc. Models don’t need notations. We (and tools) do. Unfortunately, most people don’t really get this.

The funny thing is that, most of the times I read someone citing Harry’s mantra, it is misused.

One misinterpretation of the “code is model” mantra is that we don’t need higher-level modeling languages, as current 3GLs are enough to “model” an application. The fact is: 3GLs do not provide an appropriate level of abstraction for most kinds of applications. For example, for enterprise applications, 4GLs are usually more appropriate than 3GLs. Java (EE) or C# are horrible choices, vide the profusion of frameworks to make them workable as languages for enterprise software – they are much better appropriated for writing system software.

Another unfortunate conclusion people often extrapolate from the mantra is that if code is model, model is code, and thus it should always be possible to translate between them in both directions (round-trip engineering). Round-trip engineering goes against the very essence of model-driven development, as source code often loses important information that can only exist in higher level models. The only reason people need RTE is because they use models to start a design and generate code, but then they switch to evolving and maintaining the application by directly manipulating the generated code. That is a big no-no in true model-driven development – it implies models are not precise or complete enough for full code generation.

So, what is your view? How do you interpret the “code is model” mantra?

Starting with 1.3 M1 (test build available from the milestones update site), the TextUML Toolkit is now better compatible with diagramming tools based on UML2. You can edit the source in TextUML and save it to cause model generation to occur, and any existing diagrams should still remain valid.

Here you can see the TextUML Toolkit being used side-by-side with the UML2 Tools graphical editor:

Actually, I found out that UML2 Tools can be a great companion for the TextUML Toolkit because it seems to just do the right thing when it notices the underlying model has been changed externally: new elements show up, removed elements disappear, preserved elements preserve their layout. I tried doing the same with Papyrus 1.11 and unfortunately it does not seem to handle external updates properly. I haven’t tried with other UML2-based diagram editors, so at this point I am not sure which one represents the trend here.

The TextUML compiler’s dependencies

The TextUML compiler is not very different from any ordinary 3GL compiler. It reads a bunch of source files and spits another bunch of object files. For reading and writing files, the TextUML compiler uses EFS, the Eclipse File System. For generating the object files, which are UML models, the compiler uses UML2 and EMF.

Luckily, all these components are expected to work on a standalone application, although some restrictions in functionality might apply. At a first glance, one would expect that running the TextUML compiler without OSGi should be quite feasible. But, as I should have learned by now, it is never that simple…

Extension registry without OSGi

The TextUML compiler, and some of its dependencies use the extension registry to receive contributions to their extension points or make contributions to other components’ extension points. Since Eclipse 3.2, the extension registry API provides support for creating registries without OSGi. Basically, you can add any extension and extension points you want, all you need to do is to provide the XML markup for them.

Problem: in a standalone Java application, it is the application’s responsibility to somehow find the plugin manifests and populate the extension registry.

Solution: I started with the example Paul Webster posted on the platform newsgroup almost two years ago. It basically starts from a file system location which it assumes to hold plugins, both on JAR’d and directory form. It will find plugin manifests (plugin.xml), recognize translation resources (plugin.properties), and even discover the bundle name by parsing the bundle manifest (MANIFEST.MF), and use that to populate the extension registry. Pretty cool, thanks PW. I just cleaned-up the code a bit and enhanced it to also find plugin manifests using the application’s classloader. I also had to add support for setting the default extension registry, which is the one other components will get when invoking Platform.getExtensionRegistry() or RegistryFactory.getRegistry(). Finally, I had to implement basic support for creating executable extensions, which was not too hard given that I could assume the entire application is using the same (application) classloader.

EFS without OSGi

Also since 3.2, the Eclipse File System does not require OSGi to operate, however it does require a functional registry as it uses an extension point to allow file system implementations to be plugged in. So, provided one manages to populate the default extension registry, EFS works fine on a standard Java app. No action required here (yay!).

EMF and UML2 without OSGi

EMF has long been advertised as being mostly functional when running in non-managed mode. However, when running in an standalone app, EMF does not process extensions to its extension points (such as resource factories, metamodel packages and URI mappings), so a standard Java application needs to explicitly initialize EMF, which is clearly suboptimal.  That is because EMF only processes contributions to its extension points right during bundle activation. There is no alternative way to trigger processing of the registry (see bug #271253), which sucks, given that the registry is there just waiting to be used. With no OSGi, there is no such thing as bundle activation, and thus EMF goes into autistic mode. This is also true for UML2 (not surprisingly, as they share many implementation traits), the main difference being that UML2′s extension points are much less used than EMF’s.

Problem: Ecore won’t process the extension registry when running in a standalone Java application.

Solution: Change Ecore so it allows clients to explicitly trigger processing of the contributions to Ecore’s extension points. My local hacky solution was to make Ecore’s extension registry parsers to be publicly visible so any client could invoke them.

‘platform:’ URLs without Equinox

Extensions to Ecore’s URI mapping extension often translate to ‘platform:’ URLs, which are another common Eclipse-ism, and thus not supported in plain Java applications.

Problem: No support for ‘platform:’ URL schemes  in standalone mode.

Solution: I implemented a simple URL stream handler for the ‘platform’ protocol. The current implementation complete ignores the path component that determines what bundle the resource is in. That is clearly something that needs to be improved, but should not be too hard.

Conclusion

Well, it wasn’t really a walk in the park, but other than the issue that requires a change in EMF (bug #271253, which I am hoping could be addressed for Ganymede Galileo),  I am pretty happy with the results of this exploration.

I made all the code I wrote (including my version of Paul Webster’s registry loader) available on the TextUML Toolkit’s SVN repository on SourceForge. Feel free to use it and submit improvements. I wonder if this sort of stuff could find a home in Eclipse.org, as I think many people currently developing for non-OSGi targets would like to take advantage of some great OSGi-agnostic Eclipse APIs.

After I installed the 3.5 M6 SDK, I decided to install the TextUML Toolkit 1.2…

Nothing to install?

First surprise: no features would show on the update site! WTH? Well, turns out I had the Update UI to show available features grouped by category, but the TextUML Toolkit update site does not use categories. Unchecking the option to group by categories shows the four features in the TextUML Toolkit update site as it was usual in 3.4. Phew… I was just about to enter a bug report against the Eclipse update component (a.k.a. p2), when I found out that that unintuitive UI behavior has been recently addressed and the next milestone won’t show this problem any longer.

A roadblock

I managed to install the TextUML Toolkit, and that brought along EMF and UML2, which are required features. Since, at this time, the TextUML Toolkit does not specify version range for its dependencies, the latest versions of EMF and UML2 were automatically installed by Eclipse. That should be fine, I thought, as one of the Eclipse development key mandates has always been backward compatibility. But this time around that was not the case: the TextUML builder was failing to compile a TextUML source file that was making use of template parameters. Turns out the UML2 API around templates has changed in its version 3.0. Before (in UML2 2.2), a template parameter substitution could have multiple formal and actual parameters. Now it can have only one of each, and thus the TextUML Toolkit is (partially) broken in 3.5.

So much for core values, you might be thinking? Well, to be fair, this is a bit of a fringe case. The UML2 API is an Eclipse component, and as such should strive for backward compatibility too. However, it is also a high-fidelity rendition of the UML specification published by the OMG. In this case, the OMG fixed a bug (#9838) in the spec, and as often is the case with UML, that resulted in a change that was not backward compatible. If the OMG promotes changes that are not backward compatible, the UML2 team does not have much of a choice: in order to continue to closely implement the spec, it has to break the Eclipse guidelines.

And neither do I. For the TextUML Toolkit 1.2, I will have to issue a maintenance release (1.2.1) that will explicitly depend on UML2 2.2, thus avoiding the new version, and probably becoming incompatible with other UML modeling packages that only run on Galileo and UML2 3.0. For the next release of the TextUML Toolkit (1.3), I will have to adopt the new API and explicitly depend on UML 2 3.0.

That is how life goes… for some reason, I kind of feel like a flea crawling on the back of an elephant.

But how do you do queries in UML? The obvious answer seems to be OCL, but that is not the approach I am taking as OCL and UML have serious interoperability/duplication issues. Instead, I took the  middleweight extension approach.

First, we model a protocol for manipulating collections of objects (showing only a subset here):

class Collection specializes Basic
  operation includes(object : T) : Boolean;
  operation isEmpty() : Boolean;
  operation size() : Integer;
  operation exists(predicate : {(:T) : Boolean}) : Boolean;
  operation \any(predicate : {(:T) : Boolean}) : T;
  operation select(filter : {(:T) : Boolean}) : T[*];
  operation collect(mapping : {(:T) : any}) : any[*];
  operation forEach(predicate : {(:T)});
  operation union(another : T[*]) : T[*];
  (...)
end;

That protocol is available against any collection of objects, which in UML can be obtained by navigating an association, reading an attribute, invoking an operation, obtaining the extent of a class (remember Smalltalk’s allInstances), anything where the resulting value has multiplicity greater than one.

Note most of the operations in the Collection protocol take blocks/closures as arguments. Closures are used in this context to define the filtering criterion for a select, or the mapping function for a collect.

For instance, for obtaining all accounts that currently do not have sufficient funds, this method would do it:

static operation findNSFAccounts() : Account[*];
begin
    return Account extent.select(
        (a : Account) : Boolean {return a.balance < 0}
    );
end;

Note the starting collection is the extent of the Account class. That is very similar to what is done in the context of query languages for object-oriented databases, such as OQL or JDOQL. We then filter the class extent by selecting only those accounts that have a negative balance, by passing a block to the select operation.

When mapping that behavior to SQL, we could end up with a query like this:

select _account_.* from Account _account_ where _account_.balance < 0

Another example: we want to obtain all customers with a balance above a given amount, let’s say, to send them a letter to thank them for their business. The following method specifies that logic:

static operation findBestCustomers(minBalance : Real) : Customer[*];
begin
    return (Account extent.select(
          (a : Account) : Boolean { return a.balance >= minBalance }
    ).collect(
          (a : Account) : Customer { return a->AccountOwner->owner }
    ) as Customer);
end;

Note that we start off with the extent of Account class, filter it down to the accounts with good balance using select, and then map from that collection to a collection with the respective account owners by traversing an association using collect.

If that was going to be mapped to SQL, one possible mapping would be:

select _customer_.* from Account _account_
    inner join Customer _customer_
        on  _account_._accountID_ = _customer_._customerID_
    where _account_.balance >= ?

Much of this can be already modeled if you try it out with the TextUML Toolkit 1.2. But, you might ask, once you model that, what can you do with UML models containing queries like the ones shown here?

Since the models are complete (include structure and behavior), you can:

1. Execute them. Imagine writing automated tests against your models, or letting your customer play with them before you actually start working on the implementation.
2. Generate complete code. The generated code will include even your custom queries, not only those basic ones (findAll, findByPK) code generators can usually produce for you.

If you would like to see tools that support that vision, keep watching this blog.

So, what is your opinion?
Do you see value in being able to specify queries in your models? Is this the right direction? What would you do differently?

http://abstratt.com/update/

Please see the feature page for a summary of the evolution of the TextUML Toolkit in terms of features across releases.

As usual, bug reports and feature requests are dearly appreciated. And if you need help, make sure to ask on the forum.

Acceleo is a cool open-source code generation tool that has great integration with the Eclipse IDE and EMF-based metamodels. The tool has a strong emphasis on simplicity and ease of use, which, for an open source development tool, is really a breeze of fresh air.

The Acceleo website includes a repository of code generation modules, which are extensions to the tool that target generation for specific platform/languages, such as .Net (C#/NHibernate), Java (Hibernate/Struts/Spring), Python, PHP, C, Zope etc. Of course, you can also develop your own modules, using Acceleo template editors with metamodel-driven content assist, and live sample generation.

Most of the modules in the Acceleo repository take UML2 compatible models. That means you can use the TextUML Toolkit for quickly creating your UML models using the TextUML textual notation, and then use Acceleo to generate code from them.

One of the most mature code generation modules in the Acceleo repository is the UML2 to Java EE module, which can generate code for Spring, Struts and Hibernate-based Java applications from UML2 models. A step-by-step guide would be too much for this post, but if you want to explore generating Java EE code from UML models you create using the TextUML Toolkit, here are some pointers:

Get the tools. First of all, using Eclipse 3.4, install all features from the following update sites:

• TextUML Toolkit – http://abstratt.com/update/
• Acceleo code generator – http://acceleo.org/update/
• Acceleo code generation modules – http://acceleo.org/modules/update

Once the install is complete, allow Eclipse to restart for the new plug-ins to become available.

Create your UML models and profiles. Create a project for your UML models using the TextUML Toolkit. For an example of how to do that, see the TextUML Tutorial. You will need to define in your model project a profile where you declare the stereotypes that you will use to annotate your modeled classes, to drive code generation (see how here)

Create your Acceleo generator project. The Acceleo website has plenty of documentation on how to create Acceleo code generation projects. Some pointers:

• main documentation page (instalation and tutorials)
  
• UML to JEE module documentation
  

Note that this module has a bug in which it is based on a profile with an invalid UML name which won’t work with the TextUML Toolkit out of the box. Instead of using the profile shipped with that module, you can then override the default profile and stereotypes using a properties file at the root of your generator project as shown here so to direct it to your own profile and stereotypes. You can also find a more structured guide for using Acceleo and the TextUML Toolkit together here. Even though that tutorial uses a customized version of the JEE module, it can still be helpful.

As usual. If you need help generating code from UML models using the TextUML Toolkit and Acceleo, feel free to ask for help here, or in the user forum.

Also, while testing, I noticed that the Pet Store example was triggering a known Graphviz issue with associations navigable both ends, so I updated the petstore_models project so the relationship between Title and Payment was navigable only in one direction (Title -> Payment). I recaptured the class diagram images showing on that page using the Image Viewer “Save to File” function instead of screenshot sections.

Just trigger a software update for the TextUML Toolkit to get RC2.

The feature page shows all the new features in this new release, but here they are:

• primitive types
• data types (a.k.a. structs)
• required extensions for prototypes
• behaviour modeling (a.k.a. action semantics)
• shorthand notation for aggregation and composition
• abstract stereotypes
• cross-project references

As you can tell, most of the work in the 1.2 release cycle was towards extending the TextUML notation with support for UML.

There were also several bug fixes, one of them being the first to be addressed by an external contributor (thanks, Massimiliano!).

If no serious issues are found with this milestone build, it will be promoted to 1.2 final by the next weekend. So, if you are using a 1.1.* build, make sure you upgrade it to a 1.2 release candidate build and start smoke testing with your usual workflows, and report any bugs you find.

In the article “Customizing UML: Which Technique is Right for You?”, James Bruck and Kenn Hussey (both from the UML2 team) do a great job at covering the several options for extending (or restricting) UML (James also made a related presentation at last year’s EclipseCon, together with Christian Damus, of Eclipse OCL fame). Cutting to the chase, these are the options they identify:

• using keywords (featherweight extensions)
• using profiles, stereotypes and properties/tagged values (lightweight extensions)
• extending the metamodel by specializing the existing metaclasses (middleweight extensions)
• using package merges to select the parts of UML you need (heavyweight extensions)

Each option has its own strengths and weaknesses, as you can see in the referred article/presentation. At this time, the TextUML notation supports two of those approaches: profiles and metamodel extensions.

Adding closures to UML

Even though profiles are the most popular (and recommended) mechanism for extending UML, it is not enough in some cases/applications. That has been the case in the TextUML Toolkit, for instance, when implementing closures in the TextUML action language (yes, the Toolkit eats its own dog food).

According to the wikipedia entry, “a closure is a function that is evaluated in an environment containing one or more bound variables. When called, the function can access these variables. ”

It really makes sense to (meta) model a closure as some kind of UML activity, which is basically a piece of behavior that can be fully specified in UML. Methods, for instance, are better modeled in UML as activities. Activities are composed of activity nodes and actions, which are similar to blocks of code and instructions, respectively.

The only thing that is missing in the standard Activity metaclass is the ability for a closure to have an activity node from another activity as context, so it can access context’s local variables. So here is a possible (meta) modeling of closures in UML using the TextUML syntax:

[Standard::Metamodel]
model meta;

apply Standard;

(*
  A closure is a special kind of activity that has another
  activity's activity node as context. A closure might
  reference variables declared in the context activity node.
*)
[Standard::Metaclass]
class Closure specializes uml::Activity
  (* The activity node that provides context to this closure. *)
  reference contextNode : uml::StructuredActivityNode;
end;

end.

Or, for those of you who prefer a class diagram (courtesy of the EclipseGraphviz integration):

Note a model contributing language extensions must be applied the Standard::Metamodel stereotype, and each metaclass must be assigned the stereotype Standard::Metaclass.

Of course, there is no point in being able to metamodel closures, if there is no way to refer to them. We need a kind of type that we can use to declare variables and parameters that can hold references to closures. That also means we need to be able to invoke/dereference a closure reference, and there is no support for referring to metamodel elements in the UML action language. That means we need more language extensions. But I will leave that to another post. My goal here was to show how simple it is to create a simple UML metamodel extension with the TextUML Toolkit.

What about you, have you ever needed to extend UML using a metamodel extension? What for?

This post will describe how to use models created by other UML2-compatible modeling tools from models you create using the TextUML Toolkit. I plan to cover other areas of integration in future posts.

Reading models created by other UML tools using the TextUML notation

If you have the TextUML Toolkit installed, one of the editors available for UML files is the TextUML Viewer. As the name implies, it is not really an editor, i.e., you cannot edit models with it, just visualize them using the TextUML notation. But it is an useful tool for reading UML models you don’t have the source for, i.e. models created by other UML2 modeling tools.

Using models created by other tools…

There are a few different ways of using models created by other UML modeling tools from your models created in TextUML.

…by co-location

In this method, you just drop the UML model you want to use to at the root of your TextUML (i.e. MDD) project. All models at the root of the same MDD project are considered to be in the same repository and thus you can make cross-model references by either using qualified names or importing the package and using simple names.

This method is dirty simple, but it forces you to keep the foreign model at a specific location, potentially forcing you to keep multiple copies of the model.

…with project references

In this method (available starting in version 1.2), the UML model you want to use is in a different project than the one you want to refer it from. You just open the properties dialog for your TextUML (MDD) project and add the project providing the UML model you want to use to the list of referenced projects. Now models at the root of that project will also be visible from your TextUML (MDD) project, in other words, they are also seen as part of the same repository.

This method is more powerful than the previous one, as now models can be shared by reference instead of by copying. There is a limitation still: the models you use ought to be part of some project in the workspace, so you cannot refer to models stored at arbitrary locations in the file system or models that are contributed by Eclipse bundles.

…by explicitly loading them

For this method, you use the load directive to load an external model located by a URI.

This method allows you to load any model, provided its location can be represented as a resolvable URI. That is the case of any file system path, or Eclipse platform URLs. The caveat is that some URIs such as file system URIs are not portable, so they are are bound to be invalid on other machines.

The entire truth…

…is that even if you are using only the TextUML Toolkit for building UML models, these are the same mechanisms for creating models that make cross-package references (see also the TextUML Guide). For the TextUML Toolkit, all UML2-compatible models are equal, no matter how they were created.

This milestone adds support for some UML language features:

• required extensions for stereotypes
• data types
• primitive types

But what is really exciting is that this milestone is also the first build that includes a contribution from a new member of the TextUML Toolkit team: Massimiliano Federici provided a  patch that squished bug 2127735 (revision 194). Kudos to Massimiliano, his contribution was greatly appreciated, and it seems it might just be the first of many!

[Standard::ModelLibrary]
model UMLPrimitiveTypes;

apply Standard;

primitive Boolean;

primitive Integer;

primitive String;

primitive UnlimitedNatural;

end.

As you can see, primitive types are declared using the keyword ‘primitive’, and cannot specialize other types or have structural features (thus there is no ‘end’ terminating the type declaration). To be honest, I am not sure this is the intended semantics, as the UML specification does not seem to explicitly disallow that.

Here is the breakdown of the change sets (r188-191):

• automated tests (r190)
• parser and model generation (r191)
• textual renderer (r189)
• editor (r188)

To be frank, the only test case added was quite trivial:

public void testPrimitiveType() throws CoreException {
  String source = "";
  source += "model someModel;\n";
  source += "primitive Primitive1;\n";
  source += "end.";
  parseAndCheck(source);
  PrimitiveType found = (PrimitiveType) getRepository().findNamedElement(
    "someModel::Primitive1", IRepository.PACKAGE.getPrimitiveType(), null
  );
  assertNotNull(found);
}

But it is a good start. It ensures parsing works, and the model generated has the intended element created under the right parent package.

Any suggestions of what UML feature to cover next? And what is your take? Can UML primitive types have structural features or specialize other types/implement interfaces?

(By the way, if you want to understand how the TextUML Toolkit is implemented, feature posts like this are a good starting point)

datatype UserName
  attribute firstName : String;
  attribute lastName : String;
end;

You can declare operations and specialize other classifiers as usual.

Change set

Here are the individual changes per plug-in (r177-r186):

• automated tests (180 and 185)
• parser and model generation (181, 184 and 186)
• textual renderer
• editor

There, nice and easy. Well, actually, I ended up doing a second commit because I forgot to ensure a data type specializes only other data types. But now that has been taken care of.

As usual, suggestions of UML features to support in the TextUML Toolkit are most welcome.

I really think the open source approach has lots of benefits, for the software itself and all parties involved. However, I would say it will probably take a decade before sound business models based on open source are really understood and start to become mainstream.

At this point in time, (as most people) I still think it is considerably harder/trickier to make money developing software as open source than it is with closed source. At least for small companies. A few reasons:

• reduced barrier to entry for new competitors as they can easily leverage the fruits of your hard work. Even more so if you choose a more liberal license such as a BSD, EPL or Apache (JBoss and MySQL use GPL, for instance).
• lower profit margins, if you decide to adopt a services-based business model instead of one based on selling product licenses, which is a common approach.
• the overhead of maintaining the open source software while developing the closed source extensions or providing the related services, the very activities that will actually make money, could be unbearable.

The TextUML Toolkit is open source (EPL) since release 1.1. The decision of making the TextUML Toolkit open source was based on the fact that I (a.k.a. Abstratt Technologies) never intended to make any money directly off of it, wanted to attract external contributions and maybe get some visibility to other future offerings. But I wouldn’t have done it if I had any plans of selling the TextUML Toolkit as a product on its own.

Well, I am interested in your thoughts. Do you know of cases of small companies making good money from developing and selling open source software (using liberal licenses such as the EPL)?

With the intent of starting to gather some sort of community and hopefully contributors, I decided to release version 1.1 as EPL. In the first couple of weeks after that, I noticed a significant spike in interest (page hits, issues opened, forum activity). But then everything went back to how it was before: today, there is no evidence anybody is using the tool, and I am still the only committer in the project.

So, this is a call (or a cry) for contributors: if you like the textual approach to UML modeling proposed by the TextUML Toolkit, would like to help putting together a proposal, and have some amount of time/resources to commit to the project in the long(ish) run, I am really eager to hear from you.

Things that are in scope for the project:

• broader notation coverage of UML features
• richer IDE support: content assist, search/hyperlinking, refactoring
• better integration with graphical UML tools

If you are interested, feel free to contact me via this blog, the Toolkit forum or e-mail (rafael at abstratt.com).

The following is a stereotype extending two metaclasses (uml::Class and uml::Operation):

profile my_profile;

import uml;

stereotype foo extends Class, Operation required
end;

end.

In the example above, the extension of Operation is required, the extension of Class is not.

Change set

The change set to implement required extensions in the TextUML Toolkit (issue #2266268) was quite small (btw, kudos to the UML2 project for providing the best API for UML out there).

Here are the individual changes per plug-in (r153-r156):

• automated tests
• parser and model generation
• textual renderer
• editor

Any other UML feature you would like to see exposed in the TextUML notation? Suggestions are welcome.

Here is an example of a UML model of an Account class represented in TextUML:

model bank;

import base;

class Account
    attribute accountNumber : String;
    attribute balance : Integer;

    operation withdraw(amount : Integer);
    begin
        self.balance := self.balance - amount;
    end;    

    operation deposit(amount : Integer);
    begin
        self.balance := self.balance + amount;
    end;

    static operation newAccount(number : String,owner : Client): Account;
    begin
        var newAccount : Account;
        newAccount := new Account;
        newAccount.accountNumber := number;
        newAccount.balance := 0;
        link ClientAccount(owner := owner, accounts := newAccount);
        return newAccount;
    end;
end;

class Client specializes Object
    attribute name : String;
    static operation newClient(name : String): Client;
    begin
        var newClient : Client;
        newClient := new Client;
        newClient.name := name;
        return newClient;
    end;
end;

association ClientAccount
    navigable role owner : Client[1];
    navigable role accounts : Account[0, *];
end;

end.

And here an example of a test driver ‘program’ (note the use of a closure for looping through a collection of objects):

package test;

apply base_profile;

import bank;
import base;

class TestDriver
  [entryPoint]
  static operation run();
  begin
      var john : Client, mary : Client,
             account1 : Account, account2 : Account, account3 : Account;
      john := Client#newClient("John Doe");
      mary := Client#newClient("Mary Doe");

      Console#writeln("Created: ".concat(john.name));

      account1 := Account#newAccount("1234-1", john);
      account2 := Account#newAccount("1238-2", mary);
      account3 := Account#newAccount("2231-7", john);

      Console#writeln("account owner: ".concat(account1->ClientAccount->owner.name));
      Console#writeln("account number: ".concat(account1.accountNumber));
      Console#writeln("initial balance is: ".concat(account1.balance.toString()));

      account1.deposit(2000);
      Console#writeln("after deposit, balance is: ".concat(account1.balance.toString()));

      account1.withdraw(500);
      Console#writeln("after withdrawal, balance is: ".concat(account1.balance.toString()));

       /* Now show information for all accounts. */
  	Account extent.forEach(
          (a : Account) {
              Console#writeln("*******");
              Console#writeln("Owner: ".concat(a->ClientAccount->owner.name));
              Console#writeln("Number: ".concat(a.accountNumber));
              Console#writeln("Balance: ".concat(a.balance.toString()));
          }
      );
  end;
end;

end.

And here is the output of the test driver program, produced by running it on the Libra UML runtime (not part of the TextUML Toolkit):

Created: John Doe
account owner: John Doe
account number: 1234-1
initial balance is: 0
after deposit, balance is: 2000
after withdrawal, balance is: 1500
*******
Owner: Mary Doe
Number: 1238-2
Balance: 0
*******
Owner: John Doe
Number: 1234-1
Balance: 1500
*******
Owner: John Doe
Number: 2231-7
Balance: 0

Alternatively, one could have generated 100% of the code for a target platform of choice, given that all the information necessary for that is in the model. Note that code generation is not part of the TextUML Toolkit.

Do you want to give it a try? Install M1 from the milestone update site. You can also fetch the example projects from here.

It is certainly a rough stone. I am counting on the community feedback to figure out what areas need to be smoothed first. Please provide your feedback or ask questions on the TextUML Toolkit forums.

One of the least known features of UML is that you can model detailed imperative behavior. The UML “instruction set” can do things like:

• create and destroy objects
• create and destroy links (associations) between objects
• read and write attributes and local variables
• invoke operations and functions
• throw and catch exceptions
• conditional statements
• loops

That is quite amazing, isn’t? And all that while still preserving a high level of abstraction. Such capability is generally referred to as ‘action semantics’. Action semantics provides the basic framework for executability in UML and has been there for quite a while now. It was originally added to the spec, first as patch, in UML 1.5 (2003), and then more seamlessly integrated into UML 2.0 and following spec releases.

Action Semantics and TextUML

An even more well-kept secret is that the TextUML notation supports UML action semantics and thus the creation of fully executable UML models. This support is not yet shipped as part of the TextUML Toolkit, but will be in the next release. Meanwhile, if you want to give it a try or take a closer look, you will have to grab the source from the SVN repository.

I plan to go into more details in the near future, but just to wet your appetite, here is one example of an executable UML model described in the TextUML notation:

package hello;

apply base_profile;
import base;

class HelloWorld
    [entryPoint]
    static operation hello();
    begin
        Console#writeln("Hello, World");
    end;
end;

end.

Cool, isn’t? If you had a UML runtime, this model could be executed even before you made a decision about what platform to target. Also, if your code generator were action semantics aware, you could trigger code generation for the target platform(s) of choice, with the key difference that you could achieve (or get very close) to full code generation, as the model now also describes behavior. No more of that monkey business of having to edit the generated code and manually fill in all those /* IMPLEMENT ME! */ methods.

Do you think this has value? Would you want to work with a tool that supported that? I am really keen on knowing your opinion.

Soapbox: since version 1.5, UML has had support for algorithmic behavior specification, commonly called action semantics. It is still hardly used, and most people that consider they know a lot of UML have never noticed it. Some people believe that the lack of an official concrete syntax for action semantics is a barrier to adoption. You see, the OMG defined the semantics and an abstract syntax, but left concrete syntax as an exercise for tool vendors.

As I wrote here before, I don’t really see the value in the OMG godfathering one concrete syntax over all others. Of course, we are talking here about a syntax for human beings, not for tools. Tools certainly don’t need a human-readable concrete syntax, a standard binary or XML format will do. The problem is: we all have our own preferences for what makes a good syntax, and there is no single syntax that will make everybody happy, so we are bound to have multiple concrete syntaxes anyway. We all like interoperability between tools, but when it comes to sugar, we like choice.

But maybe I am wrong. Maybe an OMG-blessed C-like concrete syntax for UML is all that is missing for Executable UML to become mainstream in the software development community. Go figure, we are an amusing bunch. Personally, I don’t care that much. I have been a Java developer for around 12 years now, so I can certainly stand another C-like syntax. We are not talking about a language anyway, it is just a syntax for an existing language, and syntax, a bit like UI, is inherently disposable, if you take it away, the real stuff is still there.

One clear positive outcome of the RFP is that submitters must provide, along with the proposal for a concrete syntax, any changes to fUML* that would be required to support such action language. That will probably help closing some gaps in the UML specification that make it hard to execute if you are stuck with the standard.

There are many other interesting bits in the proposal, but I will leave a more detailed analysis to a future post.

* the Executable UML Foundation Submission says:“Foundational UML Subset (fUML) is that subset of UML required to write ‘programs’ in UML”

I published a TextUML rendition of the UML 2.1 metamodel that is shipped by Eclipse UML2 here (warning: 5.9k lines, 370Kb of text). It starts like this:

(...)
model uml;

apply Ecore;
apply Standard;

import ecore;

(* A comment is a textual annotation that can be attached to a set of elements. *)
[Standard::Metaclass]
class Comment specializes Element
    (* Specifies a string that is the comment. *)
    [Ecore::EAttribute(isID=false,isTransient=false,isVolatile=false,isUnsettable=true,annotations=[])]
    public attribute body : String;
    (* References the Element(s) being commented. *)
    public attribute annotatedElement : Element[0, *];
end;
(...)

Thought it could be useful to anyone wanting to have a quick look at the UML metamodel. The TextUML renderer does not support all UML element types, so some elements might be missing/incomplete.

I think that is a nice demo of the textual browsing capabilities in the TextUML Toolkit. Of course, much more could be done in that area. If you feel like lending a hand, any help (bug reports included) will be much appreciated.

composition <end-name> : <referenced-type-name>;

or

aggregation <end-name> : <referenced-type-name>;

That will result in a new unnamed association with two member ends, one named, owned by the declaring classifier, with composite or shared aggregation type, and another unnamed, owned by the association itself.

Change set explained

When adding a new feature to the notation, the typical change set contains:

• updates to the affected grammar production rules
• implementation of the corresponding model generation handling code
• a few test cases.

In the case of the features presented in this post, the grammar change was quite simple (nicer view):

--- trunk/plugins/com.abstratt.mdd.frontend.textuml.core/textuml.scc	2008/09/16 05:47:13	99
+++ trunk/plugins/com.abstratt.mdd.frontend.textuml.core/textuml.scc	2008/09/16 05:47:20	100
@@ -341,7 +341,9 @@

   attribute_decl = attribute identifier colon type_identifier optional_subsetting semicolon ;

-  reference_decl = reference identifier colon type_identifier optional_subsetting  semicolon ;
+  reference_decl = reference_type identifier colon type_identifier optional_subsetting  semicolon ;
+
+  reference_type = {association} reference | {composition} composition | {aggregation} aggregation ; 

   optional_subsetting = subsets qualified_identifier | {empty} ;

In other words, where one could declare a reference, one can now declare also a composition or an aggregation (gotta love the readability of SableCC grammars…).

The corresponding model generator (a.k.a. compiler) changes were quite trivial as well, even more so if you consider I inadvertently checked in a fix to an unrelated bug around comments (just ignore the changes in lines not in the 300′s).

In terms of lines of code, the bulk of the changes were in the test class for associations, where I added three test cases. I had postponed writing tests for the reference shorthand notation, so I took this opportunity to write a test for it too.

As most test cases in the TextUML Toolkit test suite, the new test cases in AssociationTests have the following layout:

• one or more compilation units with TextUML source code are declared
• source code is compiled and the resulting errors verified (most test cases won’t expect errors)
• the resulting model is checked – were the expected elements created? Do they have the expected features?

Talking about tests

The TextUML Toolkit has a modestly sized test suite (~130 test cases) at this time. It could use dozens, probably hundreds more, but most features are covered to so some extent.

However, as important as coverage, is how much one can learn about the piece of software being tested by reading its test suite. And here is where I believe the TextUML Toolkit’s test suite shines. For example, by reading the test classes, one could (maybe more effectively than by reading the notation guide), learn how the following UML features are exposed by the TextUML notation:

• classes and structural features
  
• packages, imports, profiles
• associations
• multiplicity
• template classes

Trivia: can you find out from the test suite the difference between a private and a public package import? Give it a try and let me know if I am lying… by the way, the notation guide does not cover that yet, although the UML specification, of course, does.

According to Wikipedia:

• A diagram is a 2D geometric symbolic representation of information according to some visualization technique.
• A model is a pattern, plan, representation (especially in miniature), or description designed to show the main object or workings of an object, system, or concept.

Note that even though both terms are defined around the word “representation”, the term “diagram” implies graphical visualization, whereas the term “model” admits any kind of media, basically because models have no concrete form per se.

Now, please, if you are not convinced yet, read aloud 5 times: MODELS ARE NOT DIAGRAMS!

If that didn’t work, well, maybe the facts below will help:

• models, not diagrams, are the subject matter of model-driven development.
• models, not diagrams, can be validated.
• models, not diagrams, can serve as input to code generation.
• models, not diagrams, can be automatically generated from reverse engineering source code.
• models, not diagrams, can be executed.

Even though diagrams are commonly used for representing models, they are not the only way, and non rare not the most appropriate one (yes, I am talking again about the virtues of textual notations, but I won’t repeat myself).

P.S. Maybe it helps adding to the confusion the fact that the TextUML Toolkit has an optional feature that will generate class diagrams automatically from the UML models created with it. However, that is just an optional, loosely integrated feature, and it is definitely not the Toolkit’s thing. Weirdly enough, from my observation, that feature is the main reason most people become interested in the TextUML Toolkit. Well, go figure.

• more UML features exposed by the textual notation: abstract operations and parameter direction modifiers
• more diagram layout controls (compartments, elements across packages)
• support for exporting the class diagram to a PNG or JPG image file (actually, an EclipseGraphviz feature, also available for other graphical content providers)

Also, the TextUML Toolkit is not available any longer as a standalone download. You need to install Eclipse 3.4 first  (3.3 support was dropped) and then install the TextUML Toolkit using the new smart Software Updates mechanism in Ganymede. See new install instructions here.

As usual, feedback is most welcome – blog, issue tracker or forum, whatever option works best.

Open sourcing a product is a tough decision. Once you take that road, there is no way back, at least not without risking a backlash from the community (of course, if you managed to build a community). And even though there are more and more examples of successful businesses built on top of open source offerings, they are still the exception. However, from day one, my plan for the Toolkit has always been to give it away for free. Going from “free-as-in-beer” to “free-as-in-speech” is not nearly as traumatic.

I resisted to the idea while I was working on releasing version 1.0, as I considered it as potentially distracting and of questionable value, as then I knew exactly what I wanted to ship and how to get it done. However, now that 1.0 is out of the way, it seems the right thing to do. The first release provided a good starting point, but the project certainly needs more hands on deck to get to the next level. It is also clear that an open source license means a lot when you are catering to a developer audience.

So, you heard it here first: the next release of the TextUML Toolkit will be licensed under the Eclipse Public License. The source code is already available on SourceForge, and user forums and issue tracking are now also hosted there.

Joining the Eclipse Modeling project (more specifically the MDT subproject) is an option for the future, depending on whether the project succeeds in attracting other contributors.

Using the tool, spreading the word, asking and answering questions on the forum, reporting problems and requesting features are all great ways of helping. Regarding new features, the project needs help on two main fronts: broader coverage of UML (state machines, activities), and better IDE features (such as content assist, templates, symbolic search and refactoring). If you like the textual notation approach, the tool, and feel like you could lend a hand, please do, the TextUML Toolkit needs you!

  operation op1(in p1 : String, out p2 : String);

Java developers might consider this feature unnecessary as there is only one way of passing parameters in Java, but for distributed applications (such as those using CORBA or web services) these modifiers are quite relevant.

The corresponding support for rendering operation parameter direction kind modifiers has been added to the TextUML model viewer (decompiler) and EclipseGraphviz graphical rendering component.

This is the first new feature since version 1.0 was released.  The impact of implementing it was quite minimal to the code base, so I am looking forward to implementing the next notation feature. The question is: what feature? Any suggestions?

Moreover, we really shouldn’t care much about the actual notation being used, be it the standard graphical notation, TextUML or any other textual notation. I surely don’t. Regardless what notation you use for creating UML models, in the end there is only one language. All you know about the semantics of UML model elements is still true no matter what syntax you choose (for instance, if you know your UML, you should easily become productive with the TextUML Toolkit by just glancing over the notation guide now and then). In fact, I predict a time where people will want to move between different notations across tasks and time. Also, in the same team, different people will be collaboratively creating UML models using different notations.

This will only be possible because supporting a new concrete syntax is much simpler than supporting a whole new language (by the way, that is the same reason why I believe UML-based DSLs to be a better option than homegrown proprietary DSLs, but I digress). Any reasonably good programmer armed with a parser generator and knowledge of the metamodel should be able to write a compiler for a textual notation for UML, and Eclipse makes it really easy to provide basic IDE features such as those you see in the TextUML Toolkit. Also, there are tools in the horizon such as IMP and TMF that will make these tasks really a breeze.

Meanwhile, you can stick with what is here today.

1. making sure you have the right version of Eclipse (3.4)
2. adding the TextUML Toolkit update site
3. installing the TextUML Toolkit and EclipseGraphviz
4. configuring EclipseGraphviz to point to your Graphviz install
5. opening the Image Viewer view to show models using the graphical notation
6. creating an empty TextUML Toolkit project
7. creating an empty TextUML source file
8. creating a minimal class diagram with a package and a featureless class
9. understanding the edit/compile/visualize cycle

Give it a try and let me know what you think. Blame me for any weird screen transitions. Wink is a great little tool but has a few small quirks that I have yet to master, but the next presentation should look better. Cheers,

Rafael

That is one less excuse for using Eclipse 3.3, which was the latest release supported by Acceleo 2.2.1. An added bonus is that the TextUML Toolkit is much more stable on Eclipse 3.4 due to a nasty concurrency bug fixed in UML2 for the Ganymede release (kudos to Kenn and James!).

I just updated the install instructions for the Pet Store example application. With a new and improved Software Update mechanism (a.k.a. P2), it became much simpler to install the TextUML Toolkit and Acceleo on Eclipse 3.4. For instance, no need to worry about EMF or UML2, they are transparently installed. How cool is that?

It is basically the same as the RC3 build, made available earlier this week, with version numbers updated to reflect the status of release. You can download the TextUML Toolkit 1.0 from here.

Even if it still preserves the same humble look & feel, the TextUML Toolkit has come a long way since the first public milestone was announced here more than a year ago:

• M1 – May 2007
  • website went live
  • first public milestone
• M2 – September 2007
  • graphical class diagram visualization for Windows only (spawned as a brand new open-source project, EclipseGraphviz)
  • support for enumerations
• M3 – March 2008
  • reverse engineering of UML2 models as TextUML source (aka textual browsing)
  • diagram rendering also on Linux and Mac OS/X
  • click-through license
  • better stability and performance
  • website improvements: added user forum (SMF)
• M4 – May 2008
  • duplicate symbols properly reported as compilation errors
  • TextUML source renderer showing nested packages
  • evaluated a few code generators (Acceleo, oAW xPand, EMF JET), chose Acceleo
  • first milestone available via update site
• M5 – June 2008
  • fixed a serious memory leak caused by UML2 caching
  • several bug fixes
  • decoupled the TextUML Toolkit from EclipseGraphviz (EG becoming just a possible integration)
  • website improvements: wiki-based (MediaWiki) documentation area
• 1.0 – July 2008
  • support for applying stereotypes to stereotypes
  • provided a Pet Store-like sample application
  • more, better documentation

On the outreach front: in December, I did a quick presentation of the TextUML Toolkit during the Eclipse DemoCamp in Vancouver, and had the opportunity of doing a longer, more detailed presentation at the VIJUG’s meeting in April. At both opportunities, receptivity to the project was quite good. People seemed very keen on the idea of UML models as text, and I got lots of interesting questions.

In early June, I joined many other fellow mISVers in the 30-day product challenge. Even though I didn’t achieve everything I had set out to do, I am quite happy for having been part of it, as it provided me with the strength and courage to finally ship the first release.

Overall, I am quite happy with the current state of the TextUML Toolkit (or else I would not have declared a release). On the other hand, I confess I am disappointed that interest has not picked up yet, considering it is a free tool that provides real value. Now that there is an example describing how to use the TextUML Toolkit and Acceleo for generating code from UML models (which is the main application of the tool), I hope the value of the tool will become more apparent. And I guess more attention to the marketing side of things won’t hurt.

For the next few months, I will be focusing on a more ambitious project I have hinted at here a couple of times before. During this time, I will be promoting the TextUML Toolkit, writing more documentation and examples, and fixing any bugs users might report, but I do not plan to develop any new features unless there is user demand.

Well, it has been a fun ride, and I appreciate the interest of those of you who have followed at least some part of the journey. Your comments on the blog have been very helpful and encouraging. Thanks a lot!

Cheers,

Rafael

In addition to the sample application, the latest TextUML Toolkit release candidate (RC3) is also now available, both as a standalone download and as an update site, as usual. Work items delivered in this build:

• ticket #182 – associations end up with one single member end
• ticket #183 – cannot define stereotypes on stereotypes
• ticket #167 – provide sample application

To my fellow 30-dayers – yes, its 8 days past the 30 day deadline, but unless I get a serious bug reported during this week, this is it, I am about to achieve my modest goals (yay!) of shipping 1.0 and a sample application (remember, I started working on the TextUML Toolkit quite while ago). The only planned change for 1.0 is basically updating the splash screen to sport the elusive 1.0 version number.

Feedback on RC3 or the sample application is most welcome. As usual, feel free to comment here or on the forums.

Cheers,

Rafael

Well, enough ranting, need some sleep now. Thanks to the other 30-dayers for being part of this, and hope you guys had better luck. Cheers,

Rafael

P.S.: I considered not writing in my current mood, but I thought in the end it would be more honest doing so, so there you go

• a user reported that the embedded Graphviz install was not working for him on Windows XP (I expected it to work on all Windows versions, but really tested only on Vista). After some investigation, I realized that a minimal Graphviz install will look very different depending on the Windows version. Result: I decided to quit bundling Graphviz for Windows. Now, the TextUML Toolkit users on Windows have to manually install Graphviz on their own, and configure the location of an external Graphviz manually, just as Linux and Mac OS X users had to do since day 0. The latest build RC2 (just published) already reflects that change.
• a simple WordPress migration using GoDaddy’s Hosting Connection became a big hassle (their rollback feature did not work either). Result: had to delete my existing install, and install the latest version from scratch (thankfully, WordPress export/import features worked like a charm). Lesson learned: avoid doing any infrastructure changes that are not critical in the weeks preceding a release (even if they seem harmless).

I finally woke up to the fact I am really late with most of the deliverables I planned for June 30th and we are already a week from the deadline. I decided thus to postpone all non-product related items. Other than any critical bug that might be found this week, I will be focusing on publishing the sample application on the wiki. Nothing else.

Well, maybe some blogging.

It turned out the issue that was blocking me was not specific to Eclipse 3.4 RC3. Still, I decided that, until the end of the 30-day challenge, I will continue to use 3.3 to avoid any further surprises. I intend to go back to 3.4 shortly after that.

Another important task that was planned for the first phase (first two weeks) and I have yet to address is the sample application (models + templates). That means some of the less critical work items planned for the second phase will have to be postponed (probably the artwork item).

Even though I am behind schedule, I am really happy to be moving forward again…

Every now and then, the Eclipse Project goes through quite significant changes (OSGi and RCP in 3.0, P2 now in 3.4). And when the platform moves this fast, everybody living above feels it. New features are not well documented or are not very stable. Tooling for plug-in developers lags behind. Things that used to work before, are now broken.

That is really hard to avoid, even though backward compatibility with the previous release is a hard requirement for the Eclipse Project. I was part of the Eclipse Platform Core team in 3.0 (shipped in 2004) and even though we were having lots of fun with the move to OSGi and the birth of Equinox, it was a lot of work having to implement the new functionality and at the same time make sure all the existing use cases continued to work. And, as usual, some corner cases we missed were only discovered close to the release date, or even right after, when most people will finally migrate from the previous release. Many of the OSGi-aware features were only exposed by the plug-in development tooling in the subsequent releases. And even though we felt like all that backward compatibility effort was draining a lot of our time and energy, users would still get mad at us for introducing regressions, when they didn’t really give a damn about OSGi or RCP.

In hindsight, it is clear that all that work paid off when you look at the impact that OSGi and RCP had in the growth of Eclipse way beyond the realm of IDE frameworks. People are using Eclipse as a platform for embedded and server-side applications, or rich client applications you could swear were native. OSGi itself had a boom in adoption (and features) since when it was adopted in Eclipse and moved from niche technology into the mainstream.

I am sure the same is going to happen with P2, probably in smaller proportions (given its scope). We will be taking its features for granted two years from now, and the pain of change will have been long forgotten. And the good people developing P2 know that. But, this time around I am…

…on the other side of the fence

The plan of shipping TextUML Toolkit 1.0 (scheduled for June 30th) on top of Eclipse 3.4 (scheduled for late June – yes, that should have raised a flag) proved to be quite a challenge. I have had minor problems with the latest Eclipse SDK milestones, which I could work around, but more recently I have faced more serious, blocking issues. And even the non-blocking problems and difficulties, which are just time wasters, grow in importance when you are in a tight schedule.

So I stepped back and decided to and develop and ship the TextUML Toolkit 1.0 on Eclipse 3.3, which was last year’s release. It was not an easy decision, as I will be missing many improvements and fixes (some of them to pretty significant issues) made in the UML2 and EMF components, which are the main requirements. But at least I should be able to move forward in a more predictable pace, and be more confident I have a chance of meeting the June 30th deadline, even if quality might suffer. On the bright side, thanks to backward compatibility, the same update site should still work with 3.4, so users using the Update Manager/P2 in Eclipse 3.4 should be able to install the TextUML Toolkit features, and get better performance and stability.

What makes me feel good is that backward compatibility continues to be one of the Eclipse key values (e4 rumors aside), so regressions receive high priority and are fixed as quickly as possible. The least we (end-users and product providers) can do is to diligently report them.

After fixing a couple of bugs, I decided to add a preference page to give some level of control over the way the diagrams are laid out. Here is what it looks like:

You can now turn on or off several adornments such as association end names, multiplicities and membership. For example, this diagram was rendered using the options shown above:

Whereas the following one was rendered for the same model while having only the “Create constraints for association navigability” option checked:

As you can see, enabling constraints based on association navigability can significantly alter the diagram layout. One good reason for enabling that option is to avoid diagrams that grow too much horizontally (as Graphviz will put all nodes of the same rank on the same row), but I personally prefer the former layout.

Side note: I considered dropping the graphical visualization feature altogether for 1.0, as I see it as just a nice to have, and am not totally happy with the quality of the diagrams generated by Graphviz. But every bit of feedback I got for the TextUML Toolkit was that the graphical visualization was really nice, so I changed my mind. But unless serious bugs are found in this area, I have no plans of touching the EclipseGraphviz code again until after I complete the 30-day challenge.

Side note #2: I expanded the FAQ to cover the issue of notation choice and the role of EclipseGraphviz in the TextUML Toolkit.

It is late and I am tired, so it is very likely I have made at least a few mistakes (well, not syntactic ones, as the tool tells me about those). Of course, when I start working towards generating the code from the models, I am sure any mistakes I made will quickly emerge.

Cheers,

Rafael

This milestone was mostly about bug fixing (including a performance bug), but it also included a minor architectural change: graphical visualization is now optional, and supports different implementations.

This is the list of bug fixes:

Phase 1 – June 1st to June 15th:

Focus on finishing development and examples.

• publish the milestone 5 of the TextUML Toolkit (M5) (done)
• making UML graphical visualization an optional component (done)
• publish an example application
  • model – probably a subset of the Java Pet Store app
  • code generation templates – probably using Acceleo
• should target Eclipse 3.4 (done – M5 can be installed on Eclipse 3.4 or 3.3, but download will continue to bundle 3.3 due to lack of tool support for product creation in the new software update mechanism available in Eclipse 3.4)
• bug fixing (continuously)
• improve documentation (continuously)
• publish Release Candidate 1 on June 15th
• development freeze

Phase 2 – June 16th to June 30th:

Focus on polishing and getting it out of the door.

• major/critical bugs
• minor bugs/polish items
• improve documentation (continuously)
• artwork
  • icons for TextUML source files, new project wizard (outsource)
  • website (images, skins)*
• legal stuff
  • make sure we comply with all licenses for any bundled open source software
  • legal notices using Eclipse branding
  • beef up license (no redistribution, no reverse engineering)
• PR (go easy, this is 1.0) – EPIC, announcement-friendly developer forums
• one active beta-tester
• one early adopter*
• screencasts (this is a biggie)
  • creating a UML model using the TextUML Toolkit
  • generating code using Acceleo
• RC3 on June 29th
• declare 1.0 on Monday June 30th

* marks nice-to-have items

There you go. You, my readers (yes, both of you), can now hold me accountable if I fail to accomplish any of the work items I committed to do above.

To my fellow 30-dayers: good luck to us all. It will be fun!

Lots of interesting points, but the most negative posts are just misinformed. But that is Slashdot, what should I expect? Java and Eclipse have, in general, a poor receptivity on Slashdot, so I guess UML is in good company.

Of course, while I disagree with those that ditch UML because it was not properly employed in some project they worked, I strongly agree with the complaints about UML (graphical) diagrams being cumbersome and hard to deal with, as I have written here before. But that is not a problem with UML per se, but with the fact most still see it as a graphical language.

UML certainly has its share of problems (design by committee, no reference implementation), but I strongly believe it is very useful and that there isn’t anything out there (I am talking to you, home grown DSLs) that can replace it as the lingua franca for model-driven development.

The challenge starts on June 1st. Watch this space for frequent updates as I make progress towards the elusive version 1.0.

Rafael

Any issues or suggestions for the documentation are most welcome.

Rafael

The TextUML tutorial has been updated in order to reflect the changes that happened during M4, the most remarkable one being that starting with M4 there are no built-in packages (such as ‘base’ and ‘base_profile’) any longer, other than those defined in UML2 itself. So if you were using elements defined in those built-in packages, you have now to define the elements yourself. The rationale is that the TextUML Toolkit should not be in the business of providing built-in packages nor rely on anything other than standard UML to do its work.

If you didn’t get the test build, go ahead and download M4. If you want to see a feature in the TextUML Toolkit, now it is the time to ask, as the next milestone will be feature freeze. And if you have tried the Toolkit and decided it is not for you, we would die to know why. Your feedback is greatly appreciated.

Other tools follow the same approach. Emfatic (now an EMFT subproject) has been doing the same for EMF Ecore for a long time; the TMF project aims to be for textual modeling what GMF is for graphical modeling, and will be based on GMT‘s TCS and xText components.

Still, people are often puzzled when I explain what the TextUML Toolkit is. A common question is: “if I am going to write code (sic), why do I need UML anyway?“.

Dean Wampler from Object Mentor wrote on his blog a while ago a post entitled “Why we write code and don’t just draw diagrams“. It is a short post, but he presents very good points on why a graphical notation is usually not suficient and is bound to be less productive than a textual one when it comes to modeling details. For instance, on the saying “a picture is worth a thousand words“, Dean wrote:

“What that phrase really means is that we get the ‘gist’ or the ‘gestalt’ of a situation when we look at a picture, but nothing expresses the intricate details like text, the 1000 words. Since computers are literal-minded and don’t ‘do gist’, they require those details spelled out explicitly.”

Couldn’t have said it better.

I strongly advise you to read the original post in its entirety, but I will leave you with another pearl from Dean’s post (emphasis is mine):

“I came to this realization a few years ago when I worked for a Well Known Company developing UML-based tools for Java developers. The tool’s UI could have been more efficient, but there was no way to beat the speed of typing text.”

Enough said.

http://abstratt.com/textuml/update/

Actually, if you are planning to use Acceleo or UML2Tools, it is the best approach. From an Eclipse SDK 3.3 install, point the Update Manager to the site above and install the TextUML Toolkit along with its prerequisites (EMF and UML2). Once you are done, you can install any compatible tools, such as Acceleo and/or UML2Tools (sites will be automatically configured after you install the Toolkit and its prerequisites). If you are not planning to use Acceleo, you can start from an Eclipse Platform install, or you can just download the TextUML Toolkit from the download page as usual.

Follows a summary of the changes that went into M4, including features (in bold) and bug fixes.

I will be writing on some of those features in following posts.

Rafael

I plan to do a demo on using Acceleo for generating code from UML models, of course, using the TextUML Toolkit for modeling, which is what the next milestone (M4) is all about.

Many thanks to Manfred, the JUG leader, for organizing the meeting, and to Genologics for sponsoring it!

UPDATE: the meeting was great (slides here), got lots of interesting questions and comments, and many in the audience liked the idea of using a textual notation for UML. A bit harder to get buy-in for the idea of UML as programming language. I guess I will need to show something running to get that across too…  

• you can drop UML2 models created elsewhere into a MDD project and you can use them from your TextUML code as you would with models created using the Toolkit
• you can even decompile a UML2 model and read it using the TextUML syntax with the TextUML Viewer (which takes over as the default editor for *.uml files)
• you can auto-format the current compilation unit with Ctrl-Shift-F
• and last but not least: Linux and Mac OS X (Power PC and Intel) are now supported

The main reason for this focus on performance and robustness is that the tool must be something that people can rely upon and become productive with. From now on, real user demand must drive the addition of any new features and bug fixing efforts. So now it is your turn. Download the TextUML Toolkit and start using it for creating your UML models. It is free! If you like the approach of modeling using a textual notation, I am sure you will enjoy it. And even if you haven’t bought the idea yet, give it a try. I would be more than glad of hearing your suggestions and opinions. And more importantly, will make sure that any problems reported will be promptly addressed.

Looking forward to your comments, either here or by e-mail on the Abstratt forum. Cheers.

Rafael

The focus for this milestone was to improve the performance, memory footprint and stability of the tool, and very good progress was made in those areas. But there are also some brand new features, mostly in the area of integration with existing UML models. You can now safely add existing UML2 UML models (built elsewhere) to the project root and they will become available to the textual notation. Another cool feature in this area is that you can now double-click any existing UML2 UML model and read it using the textual notation (think “UML decompiler”). See below the sample model from Getting Started with UML2 in both textual and graphical notations:

Would you like to take a look? Grab the M3 test build, and give it a try. Please report here any problems and leave your comments. As usual, your feedback is really appreciated.

UPDATE: If the diagrams don’t show and everything else seems to work, you probably need the Visual C++ Redistributable package from Microsoft. This is a limitation that seemed to be recently introduced with the Graphviz support on Windows and the Graphviz team is looking into this issue. Sorry for the inconvenience.

Rafael

The fact is that the UML specification clearly separates abstract syntax (the kinds of elements and how they relate) and semantics (what they mean) from concrete syntax (what they look like), and states that there are two types of compliance:

• abstract syntax compliance
• concrete syntax compliance

Concrete syntax compliance means that users can continue to use a notation they are familiar with across different tools. This is important when UML is used as a communication tool in a team environment. Architects, designers, programmers and even many business analysts speak the same language.

Abstract syntax compliance means that users can move models across different tools, even if they use different notations. This is essential when UML is used as a basis for model-driven development. You might want to use tool A for creating the model, tool B for validating the model, tool C for somehow transforming/enhancing the model and tool D for generating code from it (a common form of MDD tool chain).

The TextUML Toolkit uses a textual notation that strictly exposes the UML semantics, but it is not compliant with the language concrete syntax by any means. On the other hand, the toolkit uses Eclipse UML2′s XMI flavor for persisting models and thus is fully compliant regarding the abstract syntax. That is consistent with the vision for the product: a tool from developers for developers that want to build software in a more sane way: the model-driven way. Developers can create models using a notation they are more productive with. Models can then be used as input for code generation using many of the tools available in the market. If non-developers might frown upon a textual modeling notation, they will always have the option of using their favorite graphical-notation based tools for reading the models. I mean, if their tool of choice is abstract syntax compliant as well.

Here is the first batch of questions:

1. Can a tool that uses a textual notation be considered UML compliant?
2. What are the differences between TextUML and the real UML?
3. I thought UML was all about raising the level of abstraction. Why should I go back to coding?
4. How much does the TextUML Toolkit cost?
5. Is the TextUML Toolkit open source?
6. What diagrams can I create with the TextUML Toolkit?

Do you have any questions that are not answered in the FAQ or do not agree with or understand an answer? Fire your comments, I am always happy to hear from you.