abstratt: news from the front

UML may suck, but is there anything better?

rafael.chaves — Mon, 08 Feb 2010 08:06:08 +0000

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

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

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.

Myths that give model-driven development a bad name

rafael.chaves — Sat, 06 Feb 2010 07:58:38 +0000

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

Model-driven development myths

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

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

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

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

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

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

Rafael

Interview at Modeling-Languages.com

rafael.chaves — Tue, 26 Jan 2010 04:13:18 +0000

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

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

Doing away with custom UML metaclasses in TextUML

rafael.chaves — Sun, 17 Jan 2010 09:45:17 +0000

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

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

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

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

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

What to expect

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

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

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

TextUML Toolkit 1.5 is out!

rafael.chaves — Thu, 03 Dec 2009 06:58:17 +0000

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

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

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

mdd.aliases.=
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!



Can TextUML be implemented the generative way (with Xtext or EMFText)?
rafael.chaves — Mon, 30 Nov 2009 01:49:00 +0000
I have been trying to figure out whether the TextUML notation for action semantics can be dealt with properly by tools such as Xtext and EMFText (class models and state machines should be fine). For example, given this structural model fragment:
class Advertisement
    attribute summary : String;
    attribute description : String;
    attribute keywords : Keyword[*];
    attribute category : Category;
    operation addKeyword(keywordName : String);
    static operation findByCategoryName(catName : String) : Advertisement[*];
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.



Eclipse Modeling Day in Toronto
rafael.chaves — Sat, 21 Nov 2009 03:32:07 +0000
Last Wednesday I attended the Eclipse Modeling Day in Toronto. Coming all the way from Victoria, I must have been the participant that came from farthest. Except, of course, those folks from SAP AG and Itemis that were presenting. But I was really glad to be there. I finally had the chance to chat and discuss about Eclipse and Modeling face to face with people like Simon Kaegi (server-side OSGi), Kenn Hussey (MDT UML2), Eike Stepper (CDO), Ed Merks and (fellow Brazilian) Marcelo Paternostro (EMF), Lynn Gayowski and Ian Skerret (Eclipse Foundation). It’s weird: I have been part of the Eclipse Modeling community since 2006 (and the larger Eclipse community since 2002), but had never actually met any of those folks before. Also amusing was that even though I worked for IBM Ottawa for quite a few years, my first time at the Toronto Lab was many years later as an ex-IBMer living on the West Coast.
The presentations I attended were in general very good. I had seen Ed Merks’ opening presentation on the web before, but this time I could ask questions. I got a better understanding of Xtext (great presentation!), CDO, and the Query, Validation and Transaction frameworks, some technologies I am considering adopting in the near future. I had a first time contact with the Papyrus 2.0 vision, which might provide an opportunity for increasing adoption of the TextUML notation by integrating the TextUML Toolkit into a larger modeling environment. And I liked the idea of a discussion panel at the end.
I had to catch a flight back home that same night, so I could not attend the Eclipse RT Day on the following day nor could I see any of the demos at the DemoCamp. Speaking of which, I did manage to stay long enough to have a beer on the Foundation (thanks!), and chat with Christopher Nagy from Dexterra/Antenna Software, who made a quick ad hoc demo to Ian and myself of their Eclipse/GEF-based tool for authoring multiplatform mobile applications. Very impressive!
As constructive criticism, I do agree with Bjorn that the format could use some tweaking. I sure had to miss some very promising presentations. Maybe with two presentation formats, a longer (for instance, 40-50 mins) and a shorter one (20-25 mins), we wouldn’t need two tracks. I am not sure presenters who came from Europe would have come had they had a shorter slot though. That being said, I was very satisfied with the event overall and am sincerely thankful to IBM Toronto for hosting the event, the Eclipse Foundation for organizing it, all the folks presenting and the companies sponsoring them. Thank you very much! As Lawrence wrote, hope we will see more events like this in the future!



TextUML Toolkit 1.4 is out!
rafael.chaves — Fri, 06 Nov 2009 07:51:00 +0000
Release 1.4 of the TextUML Toolkit is now available from the update sites, for both Eclipse 3.5+ and 3.4 (by the way, it is possible this will be the last major release targetting Eclipse 3.4, unless someone volunteers to generate and test builds for 3.4).
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!



Model-driven prototyping presentation @ VIJUG
rafael.chaves — Sat, 03 Oct 2009 03:59:54 +0000
Last week I did a short presentation on “Model-driven prototyping” for the Vancouver Island Java User Group (VIJUG). It was lots of fun, with good participation from the group. I also showed a quick demo of AlphaSimple, our upcoming service for model-driven prototyping, which seemed to be well received.
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.



Model-driven prototyping with AlphaSimple
rafael.chaves — Tue, 29 Sep 2009 06:49:22 +0000
It’s been a while since the last post, but I have a good excuse. I have been working on a new MDD product named AlphaSimple.
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



TextUML Toolkit 1.3 is out!
rafael.chaves — Wed, 24 Jun 2009 03:20:27 +0000
The TextUML Toolkit 1.3 is now available, 4.5 months after 1.2. If you already got RC1 (1.3.0.20090614…), it is the same build, no need to upgrade again. Otherwise, just point the Eclipse update mechanism to:
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



TextUML Toolkit 1.3RC1 is now available
rafael.chaves — Mon, 15 Jun 2009 08:33:10 +0000
The first release candidate towards version 1.3 of the TextUML Toolkit is now available. The feature overview page has been updated to reflect the changes in the 1.3 cycle.
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.



A month’s worth of news
rafael.chaves — Thu, 11 Jun 2009 07:44:29 +0000
Wow, it is been more than a month since my last post, but I have been busier than ever working on an upcoming MDD-related product (cannot say much now other than that you will hear more about it here first). However, In TextUML Toolkit-land things are looking pretty exciting.
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.



On code being model - maybe not what you think
rafael.chaves — Mon, 04 May 2009 02:04:18 +0000
I have heard the mantra ‘code is model’ several times. Even though I always thought I got the idea of what it meant, only now I decided to do some research to find out where it came from. Turns out that it originated from a blog post that MS’ Harry Pierson wrote back in 2005. It is a very good read, insightful, and to the point.
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?



New in 1.3 M1: better integration with diagramming tools
rafael.chaves — Mon, 13 Apr 2009 08:00:12 +0000
Even though it has always been possible to open models generated by the TextUML Toolkit in UML2-based diagramming tools, until 1.2 the Toolkit assigned new ids to each element every time a model was regenerated. That meant that any diagrams based on the model being regenerated would become invalid as any cross-references from the diagram to the model would be broken.
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.



Developing for Eclipse without OSGi
rafael.chaves — Mon, 06 Apr 2009 06:21:42 +0000
I have been doing some exploratory work around running the TextUML Toolkit’s compiler as a standalone Java application. In other words, without OSGi. You Eclipse/OSGi heads out there might ask: why would anyone want to do that? The answer is: enhanced applicability. Severing ties with the Eclipse runtime/OSGi means the compiler would become usable in other contexts, and by more people. Think Ant or Maven-driven builds, or  (the horror!) other IDEs.
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.



(not) Installing the TextUML Toolkit 1.2 on Eclipse 3.5 M6
rafael.chaves — Fri, 27 Mar 2009 07:37:08 +0000
I decided it was time to start using Eclipse 3.5 before it went RC or else if I find any blockers there won’t be time left for them to get fixed before the next release this Summer. I have been on the other side of the fence and know how frustrating it is when people only really start reporting bugs at the very end of the release cycle.
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.



SQL queries in UML
rafael.chaves — Wed, 18 Mar 2009 19:09:23 +0000
I strongly believe queries are an essential part of a domain model. As such, in our quest to have (UML) models that can fully (yet abstractly) describe object models for the common enterprise applications, we cannot leave out first class support for queries.
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:

Execute them. Imagine writing automated tests against your models, or letting your customer play with them before you actually start working on the implementation.
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?



TextUML Toolkit 1.2 is out!
rafael.chaves — Thu, 05 Feb 2009 02:17:01 +0000
The TextUML Toolkit 1.2 is now available, 5 months after 1.1, when it first became an open source project. If you already got RC2 (1.2.0.200902011417), it is the same build, no need to upgrade again. Otherwise, just point the Eclipse update mechanism to:
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.



TextUML Toolkit + Acceleo: generate code from UML models
rafael.chaves — Wed, 04 Feb 2009 10:06:05 +0000
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.



TextUML Toolkit 1.2 RC2 fixes stereotype extension rendering bug
rafael.chaves — Sun, 01 Feb 2009 23:01:14 +0000
A new RC build of the TextUML Toolkit is now available. It has one bug fix since RC1. Basically, when rendering stereotypes, the metaclasses extended by the stereotype were not being shown. Not really critical, but isolated and safe enough to be fixed now. Pending any last minute bug reports by the community, it is likely this build will be promoted to 1.2 release early this week.
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.



TextUML Toolkit 1.2 RC1 fixes Java 5 compatibility issue
rafael.chaves — Thu, 29 Jan 2009 06:59:26 +0000
Yikes, it happened again. A user reported that the TextUML Toolkit 1.2 RC0 build announced earlier this week wouldn’t run on Java 5 VMs (Mac users would be the most affected). This has just been fixed (one bundle was being compiled against Java 6) and a new release candidate is now available from the update site. If you too were seeing “java.lang.UnsupportedClassVersionErrors” running RC0, just go ahead and update to RC1.



TextUML Toolkit 1.2 RC0 / M3 is now available
rafael.chaves — Mon, 26 Jan 2009 03:27:55 +0000
The third milestone build and first release candidate of the TextUML Toolkit, the IDE for textual UML  modeling, is now available from the update site.
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.



Closures in UML? Extending the metamodel with the TextUML Toolkit
rafael.chaves — Sun, 18 Jan 2009 07:02:24 +0000
UML is known to be a huge language, and that has two problems: it is too complex, having way more features than most applications will ever need, and can still be insufficient, as no single language will ever cover everybody’s needs.
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?



Integrating the TextUML Toolkit with other modeling tools
rafael.chaves — Wed, 24 Dec 2008 03:22:24 +0000
No tool is an island. That is even more important when we are talking about highly focused single-purpose tools such as the TextUML Toolkit. As you probably know, the TextUML Toolkit is a tool for UML modeling using a textual notation, but that is about it. The TextUML Toolkit itself won’t help if you need features such as code generation, reverse engineering or graphical modeling/visualization. That might look as a negative thing to some, but that is by design. I am a strong believer of separation of concerns, component-based software and using the best tool for the job, and that is reflected in the design of the Toolkit.
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.



TextUML Toolkit 1.2 M2 is now available
rafael.chaves — Mon, 15 Dec 2008 10:30:53 +0000
The second milestone build towards TextUML Toolkit release 1.2 is now available from the milestone update site. Get it while it is hot.
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!



Feature: primitive types
rafael.chaves — Wed, 03 Dec 2008 03:13:52 +0000
Yesterday I checked in support for UML primitive types in the TextUML Toolkit. As an example of the syntax, here is the UMLPrimitiveTypes model, shipped in Eclipse UML2, rendered by the TextUML Source viewer:
[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)



Feature: data types
rafael.chaves — Fri, 28 Nov 2008 08:09:56 +0000
Just checked in a new feature in the TextUML Toolkit: support for data types (a.k.a. structs). This is an example of a data type declaration:
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.



Slashdot: Is Open Source Software a Race To Zero?
rafael.chaves — Mon, 24 Nov 2008 01:43:04 +0000
Great discussion over @ Slashdot: Is Open Source Software a Race To Zero?


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)?



Call for contributors
rafael.chaves — Thu, 13 Nov 2008 07:41:25 +0000
I would like to see the TextUML Toolkit as an Eclipse MDT subproject. Not long ago, I talked to Kenn Hussey and Ed Merks (they lead the UML2 and EMF projects, respectively) about the idea of proposing the Toolkit to the EMO and they both liked it (Ed actually suggested the idea in the first place). However, I was concerned that just one guy (yours truly) working on the project on and off in his spare time with no user community didn’t look very promising, and Kenn promptly agreed, so it was decided that it was important to get other people on board first.
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).



Feature: required extensions for stereotypes
rafael.chaves — Wed, 12 Nov 2008 03:02:08 +0000
Just checked in a new feature in the TextUML Toolkit: required extensions for stereotypes (honestly, I didn’t know about that feature in UML until I read this post on the Eclipse UML2 newsgroup).
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.



Executable models with TextUML Toolkit 1.2 M1
rafael.chaves — Fri, 07 Nov 2008 10:42:49 +0000
The first milestone build of the next TextUML Toolkit release is now available from the milestone update site. This preview build is the first to include support for modeling behavior using action semantics. I hinted at this capability here before, and I plan to cover action semantics in the TextUML notation in following posts. But most people will get the gist of the notation from the examples below:
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.



What can UML do for you?
rafael.chaves — Mon, 03 Nov 2008 04:50:48 +0000
Do you know what UML can do for you? I mean, did you know that UML models can actually do things?
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.



OMG issues RFP: concrete syntax for UML action semantics
rafael.chaves — Thu, 16 Oct 2008 03:53:07 +0000
This is actually old news for many people, but recently I learned (by pure chance) that the OMG issued a RFP for a “Concrete Syntax for a UML Action Language”. Letters of intent are due on December 8th. Submissions, one year after. OMG members only need apply (Aww…). I wonder if anyone in the Eclipse Modeling project is involved in submitting a proposal. Anyone?
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”



UML metamodel as text
rafael.chaves — Wed, 15 Oct 2008 06:50:34 +0000
I posted this earlier this week on the UML2 newsgroup, thought I would share it here too…
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.



Feature: shorthand notation for aggregation and composition
rafael.chaves — Tue, 16 Sep 2008 07:38:13 +0000
Shorthand notation for both composite and aggregate associations has just been checked in (r99-r100). It follows the same spirit as the existing shorthand for plain associations (a.k.a. references).
composition  : ;
or
aggregation  : ;
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.



Diagrams != Models
rafael.chaves — Thu, 11 Sep 2008 06:28:35 +0000
I often see the TextUML Toolkit being compared to tools that produce UML diagrams from textual descriptions. Examples of tools like that are ModSL, MetaUML and UMLGraph. But that doesn’t really make sense, and here is why: these tools produce diagrams from text. The TextUML Toolkit produces models from text. But what is the difference between models and diagrams?
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.



TextUML Toolkit 1.1 is out!
rafael.chaves — Wed, 03 Sep 2008 03:12:16 +0000
TextUML Toolkit 1.1 is out! This is the first release after the TextUML Toolkit became an open source project. Besides the adoption of the Eclipse Public License, these are the new features that were added in 1.1:

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.



The TextUML Toolkit needs you
rafael.chaves — Thu, 28 Aug 2008 05:10:04 +0000
Since I started working on the TextUML Toolkit more than a year ago, I have been asking myself whether it would make sense to make it available under an open source license.
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!



Feature: UML parameter direction kind
rafael.chaves — Fri, 22 Aug 2008 04:27:02 +0000
I just completed the code for supporting parameter direction modifiers. When this feature makes into the next build, modelers will be able to choose for named parameters any of the standard parameter direction kinds: out, inout, or (the default) in. By the way, the syntax for specifying return types remains the same. Here is an example:
  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?



Not yet another language
rafael.chaves — Thu, 07 Aug 2008 05:24:07 +0000
One potential downside people often point out about using TextUML as a notation for UML is that it is yet another language to learn. But that is not really a well founded argument. TextUML is not a full-blown language, it is just an alternative notation for UML, the de facto standard language for modeling. The language semantics of UML are defined in terms of an abstract syntax, and even though the specification includes sections about the graphical notation, it clearly supports the idea of alternate concrete syntaxes.
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. 



Demo: Installing, configuring and exploring the TextUML Toolkit
rafael.chaves — Tue, 29 Jul 2008 16:04:09 +0000
I just uploaded the first interactive presentation showing how to install and configure the TextUML Toolkit on Eclipse 3.4. It starts with a plain Eclipse Platform Runtime install, and guides the reader through the following steps:

making sure you have the right version of Eclipse (3.4)
adding the TextUML Toolkit update site
installing the TextUML Toolkit and EclipseGraphviz
configuring EclipseGraphviz to point to your Graphviz install
opening the Image Viewer view to show models using the graphical notation
creating an empty TextUML Toolkit project
creating an empty TextUML source file
creating a minimal class diagram with a package and a featureless class
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



One less reason for using Eclipse 3.3
rafael.chaves — Sat, 26 Jul 2008 05:59:39 +0000
According to an announcement made on the acceleo-dev mailing list, Acceleo 2.3.0 has been released today. Congrats to the folks at Obeo! The latest bits are already available from Acceleo’s update site, but the download page still shows 2.2.1 as the latest release available.
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?



TextUML Toolkit 1.0 has been released!
rafael.chaves — Thu, 10 Jul 2008 05:18:21 +0000
I am proud to announce that the TextUML Toolkit reached version 1.0!

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



Sample application, TextUML Toolkit RC3 are now available
rafael.chaves — Tue, 08 Jul 2008 08:58:59 +0000
The Pet Store-like model-driven sample application is now available. This initial version contains UML models for a few of the key entities, and generates the domain model classes and their corresponding Hibernate mapping files. I noticed the generated mapping files (or maybe the models) have a few issues and/or missing elements, but as a first stab I am quite happy. Please give it a try. It is a great way example of how the TextUML Toolkit can be used in the context of code generation, in this case, with the awesome Acceleo tool (open-source). Note this is just an example - you should be able to use any UML2-based Acceleo modules (like those available from Acceleo’s module repository) and generate code from any UML models you create using the TextUML Toolkit.
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



Time is up
rafael.chaves — Tue, 01 Jul 2008 09:05:37 +0000
Even after cutting scope to close to half of what I was planning, I failed to accomplish what I set off to do in the 30-day challenge. I basically have the code and the example in a releasable state, but I have no means to publish a tutorial with images due to some unexpected web site issues. Even without this issue, I might not have made it, given how much work I left to the last day. Anyway… after spending quite some time trying to get MediaWiki to behave (with no success), now I don’t have time or energy for packaging and pushing the bits of the TextUML Toolkit RC3 (hopefully 1.0?) to the FTP server. Should do that at some point this week, and also hopefully get the wiki back online.
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



Scope cutting season
rafael.chaves — Tue, 24 Jun 2008 09:02:04 +0000
Well, things are not going so smoothly in TextUML Toolkit land. Hope the others are doing better.

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.



Moving forward again
rafael.chaves — Thu, 19 Jun 2008 08:58:49 +0000
I finally figured out what was preventing me from exporting the product from Eclipse and worked around the problem. So the TextUML Toolkit RC1 is finally available for download, 4 days after planned.
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…



The bleeding edge: not for the faint of heart
rafael.chaves — Wed, 18 Jun 2008 08:41:06 +0000
(To my fellow 30-dayers: It has been a while since my last post in the 30-day challenge category - at least if you think of how brief it is. But worse, I am also behind the schedule. My goal was to have the first release candidate on the 15th. It is the 17th and I am not quite there yet. Read on for details) 
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.



TextUML Toolkit - Layout control for class diagrams
rafael.chaves — Thu, 12 Jun 2008 06:41:14 +0000
Contrary to my original intention of working this week on code generation and the sample application, I have been doing some improvements in the graphical visualization of UML models in EclipseGraphviz. EclipseGraphviz (a spin-off of the TextUML Toolkit) is an open source component (EPL) that integrates Graphviz into Eclipse, and among other things, can generate UML class diagrams from Eclipse UML2 models on the fly.
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.



TextUML Toolkit - Progress on the sample application
rafael.chaves — Fri, 06 Jun 2008 07:48:56 +0000
Took a first stab at creating the model for the sample application for the TextUML Toolkit. As I wrote here before, the sample application is derived from Sun’s Java Pet Store application. Take a look at the models, and let me know how the textual notation feels.
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



TextUML Toolkit M5 is now available
rafael.chaves — Thu, 05 Jun 2008 04:01:19 +0000
M5 is now available. You can download a self-contained product install, or use the Eclipse update mechanism for adding the TextUML Toolkit to your Eclipse SDK (3.3 or 3.4), on Windows, Mac OS X or Linux. Please see instructions on the download page.
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:



id

summary


171

ClassCastException if an interface has an implements section


172

ClassCastException if tagged value does not match property’s type


173

NPE for invalid input


174

resource leak in TextUML  Source Viewer


175

EmptyStackException whn multiple duplicate named elements exist


176

CoreException when cleaning up file that is use on Windows


177

show annotations for packages in source viewer


178

decouple TextUML source editor from the EclipseGraphviz viewer






TextUML Toolkit - Commitments for the 30 day challenge
rafael.chaves — Wed, 04 Jun 2008 07:58:24 +0000
As I mentioned before, I joined the 30 day product challenge with the TextUML Toolkit. Of the benefits of being part of the challenge, the ones that most attract me are the sense of being part of something greater,  and the motivational power of peer pressure (even if imaginary) and fear of public failure. With that in mind, these are my commitments for the challenge:
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!



When UML meets Slashdot
rafael.chaves — Tue, 03 Jun 2008 06:28:36 +0000
There was a recent thread about UML on Slashdot, as a reaction to this blog post . The headline: “Is UML Really Dead, Or Only Cataleptic?“. Many posters are clearly bitter towards UML. There seems to be a strong preference for using UML as a communication tool as opposed to as a basis for partial or full code generation (see post on UML modes). Many also complain that the graphical notation is cumbersome and that it hurts productivity (+1!). A few actually like UML; however, it is said that the UML specification is vast and complex and that you should pick the parts of UML that make sense for your case/goals (+1 here too).
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.



30-day challenge: the road to TextUML Toolkit 1.0
rafael.chaves — Sat, 31 May 2008 02:55:59 +0000
I decided to join a group of fellow mISVers in the 30-day product challenge. Differently from most of the other entries, which will go from product idea to release in 30 days, the TextUML Toolkit has been in development for quite a while now, so my challenge will be to finally ship the first release of the product.
The challenge starts on June 1st. Watch this space for frequent updates as I make progress towards the elusive version 1.0.
Rafael



Documentation on TextUML
rafael.chaves — Sat, 17 May 2008 01:47:55 +0000
Up until now, the TextUML Toolkit tutorial had been the only piece of documentation available on the TextUML notation. Well, not anymore. I just finished writing some reference documentation on the notation on the wiki. Since I was already at it, I also created a few topics on UML 101 with TextUML (also on the wiki), taking the text from some posts I have written on the topic.
Any issues or suggestions for the documentation are most welcome.
Rafael



M4 has left the building!
rafael.chaves — Wed, 07 May 2008 01:11:43 +0000
M4 has been declared. If you got the M4 test build that was announced a week ago, no need to download again, it is the same build. Please see that post for a summary of the changes.
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.



On code and diagrams
rafael.chaves — Mon, 05 May 2008 07:09:03 +0000
TextUML is a textual notation for UML. The TextUML Toolkit is an Eclipse-based IDE-like tool for creating UML models using the TextUML notation.
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.



TextUML Toolkit M4 test build is now available
rafael.chaves — Mon, 28 Apr 2008 09:31:54 +0000
The first (and hopefully only) test build for M4 is now available. This is the first milestone where you can get the TextUML Toolkit via Update Manager. Just point Update Manager to:
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.


Ticket
Summary


49
prevent creation of duplicated symbols


102
NPE trying to set value for stereotype property


143
declare a built-in update site for the textuml toolkit


145
project creation wizard issues


164
Support nested packages in TextUMLRenderer


165
Unexpected exception while compiling - java.lang.IllegalStateException: deresolve relative URI


166
spurious empty null.uml or base_profile.uml files being created


168
integrate a code generator


169
constant literal assignment is broken


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



Lightning Talks at VIJUG
rafael.chaves — Mon, 14 Apr 2008 05:58:15 +0000
The next VIJUG meeting will follow the Lightning Talks format. Last December, I attended the Eclipse Democamp in Vancouver which had a similar format and it was quite dynamic and fast-paced. I am looking forward to VIJUG’s first meeting using this exciting format.
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.



TextUML Toolkit at VIJUG
rafael.chaves — Wed, 26 Mar 2008 09:18:16 +0000
I will be presenting the TextUML Toolkit at this month’s Vancouver Island Java User Group meeting. If you are in the Victoria area, I hope to see you there. It is free, and there will be pizza and drinks. Oh, and there will be a cool demo of the toolkit, including code generation using Acceleo and a quick demo on model execution just to give a hint of what comes next after the toolkit goes GA.
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… ;) 



TextUML Toolkit is now available on multiple platforms
rafael.chaves — Mon, 03 Mar 2008 08:17:27 +0000
The latest milestone (M3) of the TextUML Toolkit has been declared today, as promised earlier here. As I said before, the focus for this milestone was stability and performance, so you can expect a much snappier and more solid tool. But it also includes some cool new features:

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



TextUML Toolkit M3 test build is available!
rafael.chaves — Fri, 29 Feb 2008 06:26:10 +0000
A TextUML Toolkit M3 test build is now available from the download page. If no serious issues are found in this build, it will be declared the final M3 build later this week.
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



Textual notations and UML compliance
rafael.chaves — Fri, 08 Feb 2008 06:22:42 +0000
One common misconception is that UML is a graphical language and that any tools adopting alternative notations (such as a textual one) are inherently non-compliant. That can’t be farther from the truth. Read on to understand.
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.



Frequently Asked Questions about the TextUML Toolkit
rafael.chaves — Sun, 27 Jan 2008 10:18:34 +0000
I just added a brand new FAQ section to the web site. It was long overdue.
Here is the first  batch of questions:

 Can a tool that uses a textual notation be considered UML compliant?
 What are the differences between TextUML and the real UML?
 I thought UML was all about raising the level of abstraction. Why should I go back to coding?
 How much does the TextUML Toolkit cost?
 Is the TextUML Toolkit open source?
 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.



A reader’s “Thoughts about TextUML”
rafael.chaves — Tue, 18 Dec 2007 08:39:02 +0000
Andreas Awenius, from Empowertec, was kind enough to devote not only one, but two blog postings on the TextUML Toolkit. While his first post was just a paragraph or two acknowledging the use of a textual notation for UML modeling in the TextUML Toolkit, his second post was a very detailed and balanced analysis on the whether using textual notations is a good idea. Even though the conclusion of his posting is that a graphical notation is superior to a textual one, I still agree with many points Andreas has made in his analysis:

the presentation notation and the persistence format are completely unrelated concerns (exactly, see my previous comment on this).
diagrams are views for models, focused on a specific aspect, and as such must show only what is needed and omit anything that is not essential. (perfect)
there are “multiple ways to manipulate the repository, e.g. the conventional - graphical - way or a textual notation”. (yes!)

These are the very same facts that justify the existence of a tool such as the TextUML Toolkit.

since user-oriented notation and persistence format are completely different things, you can please users with the most appropriate syntax for their needs (and that is text for many developers), without affecting interoperability with other tools, as tools interoperate at the level of the persistence format. The TextUML Toolkit achieves that by producing UML2 models as the native object file format.
the graphical notation is great for creating views, but it is not that suitable for exposing all the details in a model. A textual notation has no problem doing that. The graphical notation is still useful, and this is why TextUML Toolkit will include a read-only graphical view for browsing the repository. And here is the first point I disagree with Andreas. He says: “a diagram must carefully be crafted manually, leaving out all irrelevant detail”. I say: automatically generated diagrams can still obey a set of preferences defined by the user (level of detail, color, font, etc). UMLGraph has been doing this for a long time (albeit by breaking some basic rules of separation of concerns, but I digress). The TextUML Toolkit will embed an upcoming version of UMLGraph in its next milestone.
this is basically a conundrum of points #1 and #2. The model created will be the same (from the point of view of tools) regardless the user-facing notation. If users say they would rather use a textual notation, why forcing them to use a graphical one when there are no technical reasons to do so? Here is where Andreas makes several points to back his opinion based on technical and strategical reasons, most of which I (strongly to moderately) disagree. Instead of trying to refute each of those arguments (that is not how you encourage people to provide elaborate feedback), I will use them as an opportunity for driving awareness efforts around the Toolkit, the notation and our future offerings in upcoming posts to this blog.

The ‘raison d’être‘ for this blog is to establish connections with the modeling community at large, users and tool providers. I really appreciate the time and energy that Andreas committed to sharing his views on the TextUML Toolkit and the textual notation approach and am both grateful and honored for that. Thanks a lot, Andreas. Stay in touch. I hope at some point I can convince you that you are wrong! 



Eclipse DemoCamp in Vancouver
rafael.chaves — Sat, 08 Dec 2007 09:56:56 +0000
Last Thursday happened the 1st Eclipse DemoCamp in Vancouver. It was a very dynamic event, with nine short talks packed into little more than  one and a half hours. Attendance was high, I was really amazed to see such a great turnaround. The audience saw a diverse range of interesting Eclipse-based projects being developed in Vancouver/Victoria.
I demoed the TextUML Toolkit and got good feedback and some very interesting questions.  The idea of a using a textual notation for creating UML models is still not a very easy sell, and that continues to surprise me. Being a developer, I find working with a textual notation so much more natural than a graphical one that it makes it hard for me to see things from other people’s shoes. I plan to go over the issue of textual versus graphical notations on a future post.
All in all, it was a great event. Many thanks to Tasktop’s Robert Elves and Mik Kersten for organizing it, to the Eclipse Foundation for sponsoring the event, and congrats to all presenters.



The two EMFs
rafael.chaves — Sun, 02 Dec 2007 02:17:35 +0000
In a recent thread on the EMF newsgroup, I came to realize that there are (at least) two EMFs, each belonging to a different class of product, and attending completely distinct requirements.
EMF’s native metamodel, Ecore, is a generic, lean object-oriented metamodel based on a subset of UML.
EMF’s runtime framework provides Java applications with runtime support for object	models “including change notification, persistence support with 	default XMI serialization, and a very efficient reflective API for 	manipulating EMF objects generically” (source).
I am a happy user of EMF’s Ecore metamodel as a poor man’s UML (EMF team, please take that as a compliment). From Ecore-based models, using a compatible template engine, I can generate all code/artifacts that are prone to automation, be they Java code or not.
The runtime aspect of EMF is certainly useful to many applications, but certainly not to all or maybe even most. That is not to say that the EMF runtime does not provide a lot of value, as it clearly does given its popularity. Nor does it imply that the EMF runtime API has design flaws that prevent its use to be more widespread.  The fact is that frameworks, while designed for extension, always impose a certain set of architectural decisions in order to provide value out-of-the-box. Those decisions are bound to make its use more suitable to some scenarios and applications than others. The goal is to make as many people happy as possible. It is clear that the EMF team has pulled off that trick. But that does not mean that using EMF-generated model code is appropriate for every Java application out there.
Model driven development maximizes reuse via a complete separation between problem domain and technological concerns. This separation is critical to allow us to build software in an obsolescence-proof way. EMF’s Ecore  provides a good foundation for MDD in this sense, regardless the technology choices for the software being developed. The EMF runtime framework, albeit a valuable tool for a significant range of applications, brings with it a specific set of choices in terms of design and implementation decisions, and as such has a less universal applicability.
However, time and  again I read comments in the EMF newsgroup that lead me to believe that this duality might have been accidental, and that the sole reason Ecore was created was to support the generation of Java applications based on the EMF runtime. If that is really the case, this is something that both amuses and worries me. My concern is that if the EMF team does not acknowledge the importance of Ecore as an independently useful product, technical decisions in the evolution of EMF might break the use of Ecore in contexts other than EMF-based Java applications.



UML 101 with TextUML: multiplicity (or [*])
rafael.chaves — Sat, 17 Nov 2007 19:33:57 +0000
One weird thing about UML is that there aren’t collection types or array types. Basically, multiplicity and typing are totally independent concerns, represented by the metaclasses TypedElement and MultiplicityElement.
A typed element is a named element that has a type, and that is all about it. Examples of typed elements are value specifications, properties, parameters, pins and variables.
A multiplicity element, on the other hand, is an element that when instantiated potentially admits a collection of values.  An optionally defined lower bound value (defaults to 1) can determine the minimum number of instances expected. Whether multiple values are in fact admitted will depend on the upper bound of the multiplicity element, which defaults to 1  (no multiple values allowed), but can be set to any positive integer, or infinity. A multiplicity element that can actually be multivalued can also be characterized regarding ordering (whether values can be accessed by position) and uniqueness (whether values can be repeated).
Some kinds of elements are both typed and support multiplicity (such as properties, parameters, pins and variables), however a few are one or the other (let’s ignore those in this discussion).
Mapping UML to Java
To try to illustrate all that was said above, let’s see a few examples of Java variable declarations and the equivalent declaration in UML (using TextUML syntax):


declaration
Java
TextUML


single-valued
Client c
c:Client


multi-valued
Collection c
c:Client[*]


Client[] c


ordered
List c
c:Client[*]{ordered}


unique
Set c
c:Client[*]{unique}




There are few interesting differences though:

in UML, it is the typed element itself that defines multiplicity, and not the type
c:Client, c:Client[1] and c:Client[1,1] are all equivalent
c:Client[*], c:Client[1,*] are equivalent
if a value is optional, the lower bound must be specified to be 0 (example: c:Client[0,1]). There is no  Java equivalent for that.
unique and unordered are the default in UML (you can use the modifiers ‘nonunique’ and ‘ordered’ to override the defaults)

There are some implications related to assignment when the source and destination are multiplicity elements:

the upper bound of the destination must be the same or greater than the upper bound of the source, or a type mismatch will ensue
what happens if source and destination differ on ordering or unicity? The UML spec does not sem to cover that (let me know if you think otherwise). In TextUML, any required transformations are performed automatically behind the scenes. For example: if the source is non-unique and the destination is unique, duplicates will be silently suppressed, or if the source is unordered and the  destination is ordered, an arbitrary order will be defined.

Well, that was it for today. If you have questions, suggestions or think I got something wrong here, feel free to add a comment.



UML 101 with TextUML: the Templates package
rafael.chaves — Fri, 02 Nov 2007 04:22:10 +0000
One of the least known and understood concepts of UML is templates. Section 17.5 on version 2.1.1 of the UML specification covers the Templates package in 31 pages. What follows is an attempt at providing a summary of the mechanism in a way that is easy to understand without actually omitting any important details.
A simple example
The following example in TextUML should be easy to understand for any developer familiar with C++ parametrized types  or Java generics:
class Foo
end;

class Bar
    attribute prop1 : T;
    operation op11(par1 : T);
end;

class Fred
    attribute attr1 : Bar;
end;
Class ‘Bar’ is a template class, whose template signature contains a single parameter: ‘T’. The type of the property ‘prop1′ is defined as the template parameter ‘T’. Class ‘Fred’ declares ’someOp1′, an operation that takes a parameter whose type is a binding of the template class ‘Bar’. ‘Bar’’s template parameter ‘T’ is bound to the class ‘Foo’. Implicitly, the type of ‘Fred.attr1′ when expanded against Foo should look something like:
class BarOfFoo
    attribute prop1 : Foo;
    operation op11(par1 : Foo);
end;
Note that the expanded class has actually no name, but I am calling it ‘BarOfZoo’ for pedagogical reasons.
Looking closer at the abstractions



TemplateableElements - abstract super-class for elements that can be declared as templates, or that can bind other templates to a set of parameters. Four kinds of elements can be declared as templates in UML 2.*: Classifier, Operation, Package and StringExpression, and thus only those metaclasses specialize TemplateableElement*.
ParameterableElements - abstract class that is specialized by any type of element that can be used as parameters to templates.
TemplateSignature - a template signature is owned by a template element and contains the set of parameters declared by a template element.
TemplateBinding - a template binding represents the “instantiation” of a template in the form of  a directed relationship between a template signature and a a bound element, another templateable element. In addition to tying the template to the bound element through the template’s signature, the template binding contains a set of template parameter substitutions. Which takes us to the next abstraction…
TemplateParameterSubstitution - a template parameter substitution is created for every template parameter declared by a template signature. It binds an open parameter to an actual parameter, which is a ParameterableElement.

Would you like to play with templates in UML? For now, you will have to look elsewhere. There is some support for templates in the TextUML Toolkit 1.0 M2, but it is, to put it mildly, half-baked. Full template support is planned for M3 (whenever it happens), and that is exactly what I am working right now. I know I am close to getting it right, but assignment compatibility involving template/bound classifiers get be really tricky to implement. Well, whenever I am done, you will learn it first here.

*in the Eclipse UML2 API, Property also specializes TemplateableElement. That seems to be a deviation from the spec, and a bug report has been submited.



EclipseGraphviz on non-Windows platforms
rafael.chaves — Thu, 27 Sep 2007 06:43:48 +0000
Starting today there is support for EclipseGraphviz on non-Windows platforms. Scott Bronson convinced me that while bundling a Graphviz install was a good idea for the Windows audience, on Linux and other platforms that really would not make sense given that Linux runs on many different architectures,  not to mention other Unix-like systems where Eclipse and Graphviz are known to work and EclipseGraphviz would not due to lack of a corresponding bundled Graphviz install.
Thanks to Scott’s patches, EclipseGraphviz should now work out of the box on any Windows system or on any other platform where Eclipse and Graphviz were successfully installed. If Graphviz is installed under a location that is not part of the system path, you will have to open the Graphviz preference page, choose the “Specify manually” option and enter the absolute location of the “dot” executable:

Do you create diagrams using Graphviz dot language or would you like to see the UML visualization capabilities on non-Windows platforms? Make sure you have Graphviz installed (Windows users can skip this step), then point the Eclipse update manager to http://eclipsegraphviz.sf.net/update and get the latest build. Any problems, report here or on the EclipseGraphviz issue tracker. Need help? Ask away, either here or on the forum. We only tested on Windows XP and Linux/x86 64 bits so if you are using another platform, please tell us what OS/architecture you are using EclipseGraphviz on and whether it works or not.



EclipseGraphviz gets an update site
rafael.chaves — Wed, 19 Sep 2007 07:34:56 +0000
A few people have asked for a more convenient way of getting EclipseGraphviz other than by checking it out from the Subversion repository on Sourceforge, so I decided to create an update site with the most current code. Again, this is alpha code, so proceed with caution.
Check out the EclipseGraphviz wiki on instructions for installing EclipseGraphviz from the update site and a few hints on how to use it.
Enjoy. Feedback is most appreciated.



TextUML Toolkit M2a - Java 5 users please read
rafael.chaves — Sat, 08 Sep 2007 19:36:08 +0000
A user has just reported that the TextUML Toolkit M2 build did not work at all for him. Ouch. Thankfully, the user included in the bug report all the information I needed to allow a quick diagnostic: turns out he was using a Java 5 VM, and he was getting exceptions like this:
java.lang.UnsupportedClassVersionError: Bad version number in .class file

 at java.lang.ClassLoader.defineClass1(Native Method)

 ...
I then realized that for the M2 build some of the plug-ins were accidentally compiled having Java 6 as the target platform, and thus wouldn’t work on a Java 5 VM. This is being fixed as I write this, and a new M2a build will be available shortly.
So, for those of you running with a Java 5 VM, please make sure you download the TextUML Toolkit M2a build. Otherwise, if you are using a Java 6 VM, you should be fine with M2, no need to download the build again.
Thanks to Jon for reporting the issue. Keep those bug reports coming!



UML 101 with TextUML - Profiles and Stereotypes
rafael.chaves — Fri, 07 Sep 2007 05:09:14 +0000
Profiles and stereotypes form a lightweight mechanism for extending the UML metamodel.
A stereotype allows you to tag elements in your model so they can be interpreted differently from ordinary model elements, much like annotations work in languages such as C# and Java. These tags can then be used to drive code generation, for example, so for every class marked as “persistent”, appropriate persistence code should be generated.
A profile is a special kind of package intended to contain stereotype declarations that extend UML to cover some specific domain or platform.
Let’s see how to declare and use profiles and stereotypes with the help of the TextUML Toolkit.
Declaring a stereotype
To declare a stereotype in TextUML, one uses the following syntax:
profile ;

stereotype  extends ; [... property-n;]…]
end;

end.
In other words, a stereotype can be declared as applicable to one or more metaclasses (i.e. types of elements in a UML model), and a stereotype can optionally declare properties (more on properties later) . For instance, a classes could be tagged with the <> stereotype:
profile business_apps;

import uml;

stereotype persistent extends Class
end;

end.
Or operations could be marked as <>, meaning that a transaction will be started whenever the operation starts executing, and finished when its execution ends:
profile business_apps;

import uml;

stereotype transactional extends Operation
end;

end.
Any UML element can be affected by stereotypes, but stereotypes are declared as targetting (potentially multiple) specific element types. For instance, the UML specification has an example of a profile for Enterprise JavaBeans that defines a <> stereotype for session beans. The<> stereotype declares a property that allows modelers to define whether the session bean component is stateful or stateless.
profile EJB;

enumeration StateKind
  STATELESS, STATEFUL
end;

stereotype Bean extends uml::Component
end;

stereotype Session specializes Bean
  property kind : StateKind;
end;

stereotype Entity specializes Bean
end;

end.
Applying a stereotype
Now that we know how to declare stereotypes, lets see how to use them. First of all, you must apply the profile defining the stereotypes to the model declaring elements you want to apply stereotypes to:
model bank;

apply business_apps;

/* other model elements here */

end.
You can then attach stereotypes defined in the applied profile  to the suitable model elements in your model:
model bank;

apply business_apps;

[persistent]
class Account
    attribute accountNumber : base::String;
    attribute balance : base::Real;
    attribute changes : AccountChange[0,*];
    [transactional] operation withdraw(amount : Real);
    [transactional] operation deposit(amount : Real);
    operation balance() : Real;
    [transactional] operation transfer(other : Account, amount : Real);
end;

end.
In the example above, we applied the <> stereotype to the Bank class, and the <> stereotype  to the withdraw, deposit and transfer operations. In order to have access to these stereotypes,  we had to apply the “business_apps” profile to our model.
Conclusion
In this post/article on UML basics using TextUML, we saw how to declare stereotypes and apply them to elements in UML models. We learned that a stereotype must explicitly declare the metaclasses they are applicable to, and that optionally stereotypes might declare properties. Finally, we saw that before a stereotype can be used in a model, the profile declaring the stereotype must be applied to the model.



Rendering UML2 models with Graphviz
rafael.chaves — Sun, 02 Sep 2007 08:28:33 +0000
The primary goal of the EclipseGraphviz project  is to support Eclipse-based applications that want to use Graphviz as an easy way of producing non-interactive structured diagrams without requiring the complexity of GEF or GMF.
The TextUML Toolkit is the only application currently known to be based on the EclipseGraphviz project. To support rendering UML models generated using the TextUML textual notation, EclipseGraphviz has now the ability of rendering any UML model generated using the Eclipse UML2 API.
In this screenshot, you can see the UML model used in the article “Getting started with UML2” rendered with EclipseGraphviz:

The main benefits are that the EclipseGraphviz graphical rendering of UML2 models is quite lightweight, and Graphviz produces great layouts automatically. The main caveat is that the diagrams are not interactive. Not to mention that EclipseGraphviz is still quite in its early stages, so it lacks maturity and features. And it does not run yet on non-Windows platforms.
There is where you can make a difference. Check out the project from the Subversion repository,  give it a try, and  contribute with bug reports, feature requests and patches.



TextUML Toolkit 1.0 M2 is available!
rafael.chaves — Sun, 02 Sep 2007 07:56:37 +0000
After a few minor bug fixes and improvements to the test build, the M2 milestone of TextUML Toolkit is available. With this milestone you can:

create UML models using the TextUML textual  representation
visualize the model created using the conventional graphical notation for class diagrams

This milestone does not support non-Windows platforms. But progress is being made in that direction. See below a screenshot of TextUML Toolkit running on Ubuntu Feisty Fawn:


Just go to the download page and fetch it, it is free with no restrictions (or guarantees). Make sure to check out the tutorial. Your feedback is most appreciated.
Now off to a long weekend on the beach…



TextUML Toolkit 1.0 M2 test build is available
rafael.chaves — Wed, 29 Aug 2007 16:03:50 +0000
A TextUML Toolkit 1.0 M2 test build is available off the download page. If no serious issues are found in this build, it will be declared the final M2 build later this week.
The key feature developed for this milestone is the graphical class diagram viewer, which reuses the EclipseGraphviz project. The viewer shows a live representation of the UML model built from your TextUML source file using the standard graphical notation. It can also be used to visualize UML files created by any UML2 compliant tools.

Other significant change is that the “extends” keyword is now used specifically to state the metaclass a stereotype is a applicable to, whereas “specializes” should be used for class inheritance. This was for a better alignment with the official UML terminology. Finally, there is now support for declaring enumerations.
Would you like to take a look? Grab the M2 test build, and give it a try. Your feedback is much appreciated.
RC



A detour from a detour from a detour (or how a graphical viewing framework for Eclipse was born)
rafael.chaves — Thu, 23 Aug 2007 17:04:59 +0000
In the context of providing class diagram visualization for TextUML Toolkit, I have developed a simple graphical viewing framework for Eclipse. It is content type based, and allows you to view anything a content provider has been registered for. For instance, any image file supported by SWT:


But you can also view  the graphical  representation of a Graphviz DOT file, and it will even update as you edit the file:


And finally, and also the reason why I had to develop support for DOT visualization in the first place, you can also visualize a UML model (here showing a model created using the TextUML Toolkit):


All these features  (except for the TextUML Toolkit itself) are part of the EclipseGraphviz project, which is open source (EPL). No releases yet as this is still very new, but you can grab the source from the Subversion repository. If you would like to contribute to the EclipseGraphviz project, or to the graphical viewing framework, your help will be most welcome.
RC 



Graphviz on Eclipse - first cut
rafael.chaves — Fri, 03 Aug 2007 07:36:38 +0000
Just finished a raw implementation of a viewer for GraphViz dot files. Here is a screenshot:

By the way, the project has been provisioned on SourceForge with the suggestive name of EclipseGraphviz.
RC



Graphviz support in Eclipse
rafael.chaves — Mon, 23 Jul 2007 07:35:57 +0000
Would you like an Eclipse-based development environment for composing Graphviz diagrams, for instance, an editor with syntax highlighting, on-the-fly validation and visualization? Or would you, as an Eclipse plug-in developer, like an easy way of producing nice looking diagrams by calling Graphviz from your own Eclipse application?
Well, we have the second need (for our TextUML Toolkit product) and I have started developing it as an open source project to be maintained on SourceForge (project being provisioned as I write this). We will certainly need help from other contributors. Help will be mostly welcome with the end-user oriented features as our initial focus will be on producing an API for invoking Graphviz from within Eclipse.
(By the way, it has been a while since the last post.  Meanwhile, I have been busy moving back from Brazil to Canada (more specifically to the beautiful Victoria, BC), finding a new home and buying a new computer. The trip itself was exhausting (5 flights across a week), but it could have been much worse had I followed Google’s advice.
From now on, you should see a new post here at least once a week. The plan is to have the second milestone for TextUML Toolkit (with diagram visualization) in about two weeks. Stay tuned.)



Full code generation from UML class, state and activity diagrams
rafael.chaves — Fri, 01 Jun 2007 23:36:19 +0000
UML has become the lingua franca for modeling applications using the object-oriented paradigm. People use UML in many different ways (see the post on UML modes), ranging from as a communication tool to as a full fledged programming language that supports full code generation. This last way of using UML should puzzle most readers - how can UML models lead to full code generation?
UML has two diagrams that are used for behavior specification: the activity diagram and the state diagram. These two diagrams (more one than the other, depending on the nature of the subsystem being modeled), plus the class diagram (for modeling the structural aspects of the object model) provide the framework that supports the design of complex applications in a way that is fully complete (and thus allowing 100% code generation) while still implementation independent (see earlier post on platform independence). All the other diagrams (use case, sequence, collaboration) are interesting for gathering requirements, but are useless in modeling a solution that can be automatically transformed into a running application, and thus we will ignore them here.
Specifying structure with the Class Diagram
The class diagram is the most well understood of all diagrams in UML. You can model all structural aspects of your object model in the form of classes, attributes, operations and relationships between classes. This specification of structural aspects can then be used for generating (boilerplate) code, database schema, configuration files and so on so forth. This is great already, as that is most of the work. But without including behavioral aspects, it is impossible to do full code generation solely from the class diagram, you are forced to fill the empty methods with handwritten code (unfortunately this is how most vendors expect you to do model-driven development). Still, the class diagram is a fundamental one in which it provides a base framework the other diagrams can build upon.
Specifying dynamics with the State Diagram
The UML state diagram (derived from David Harel’s state charts) allows for a full design of the dynamic aspects of a system. One can model complex state machines using the state diagram, always in the context of a class described in the class diagram. Many mainstream applications do not have any interesting dynamics though, so in those cases the state diagram has limited value. However, in applications for certain industries (such as robotics, telecom and automotive) it is the most important diagram.
Specifying business logic with the Activity Diagram
The most underrated of the UML diagrams, the activity diagram has a key role: it is the only one to allow the modeler to specify behavior in a precise way. The Activity Diagram provides elements (such as actions, pins, data and control flows, signals) that allow specifying the meaning of a behavioral element (such as the body of an operation from the class diagram, or the effect of a state transition from the state diagram).
But no matter how important the UML activity diagram is, it has one strong limitation: it demands too much detailed information in order to be fully defined (and thus actually useful in the context of code generation). Any simple logic that could be written in a few lines in, say, Java, requires a graph with so many nodes that it is virtually impractical to use it with the graphical notation, severely hampering its more widespread adoption.
Have I just suggested that activity diagrams are useless for any serious usage? No! It is just the case that the graphical notation is too cumbersome, and it is not just a problem with the specific choice of symbols - there will never be any graphical representation that can be as expressive and concise for specifying behavior as your programming language of choice (even if your favorite language is as verbose as COBOL). So it is a matter of representation: a textual notation is much more appropriate than a graphical one. The activity diagram itself is fine, thanks.
So what is the textual notation for the activity diagram?  There is none. I mean, not one defined by the OMG. Many companies have defined their own action languages (such as Pathfinder AL, Bridgepoint OAL, Kennedy Carter’s ASL) with compilers that provide a textual front-end for the UML activity diagram. TextUML itself has a bigger cousin (currently an ongoing work) that allows specifying UML activities in a way that is familiar to any programmer. Want to see what an action language looks like? Expect a new post on the subject (including our very own action language) here soon.



Model-driven development improves reuse
rafael.chaves — Wed, 30 May 2007 22:49:49 +0000
One notable benefit of model-driven development that is often underrated is improved reuse. This is a direct consequence of appropriate separation of concerns promoted by this development approach. The more intertwined concerns are when addressed in a piece of code, the harder it is to reuse that piece of code. The reason is simple: whenever you tie a solution for one concern to a solution for another concern, you are in trouble: you cannot reuse that piece of code where only one of the concerns is relevant, or the solution for one of the concerns is not appropriate (even if the solution for the other concern is).
Model-driven development promotes an approach where problem-domain concerns are addressed separately from implementation concerns. That means artifacts dealing with problem-domain concerns are free from any specifics on target platforms, and also that artifacts addressing implementation-related concerns are totally unaware of any problem domain knowledge.
That is fantastic, and the reason is twofold:

 it makes it viable to build a repository of platform-independent problem-domain specific components, likely created by people that are experts in their domain, that can be reused on different target platforms;
it allows implementation specialists to code their technology-specific implementation strategies as standalone artifacts (i.e. templates), which can then be shared and reused in applications for the most varied problem domains.

The software industry has been looking for a long time for a way of encapsulating knowledge about specific problem domains in the form of platform-independent software components. Model-driven development with true executable models enables that dream.
For many decades, valuable business logic has been imprisoned into obsolescence-prone implementation-specific artifacts. We are working hard on a product that will help stop this insanity and finally make the dream of truly reusable component repositories a reality.



Platform independence in MDA
rafael.chaves — Tue, 22 May 2007 15:33:17 +0000
One key aspect of MDA is platform independence. However, even some of the brightest people in our industry misunderstand what platform independence means in MDA.
Platform independence has a different meaning in MDA than it has, for instance, in Java. Java promotes platform-independence by providing a common environment that insulates the application from platform details such as the instruction set and system API (for instance, for memory allocation, file system manipulation, networking, GUI,  threading, etc).  The application still has to address all these concerns, but it does that through API and mechanisms that work the same way regardless the actual underlying platform, and thus can run on any platform the Java environment is available. In other words, the Java environment is the platform.
MDA promotes platform-independence by adopting a design-centric approach. Models are removed from implementation related concerns and thus are inherently platform independent: a single design can be reused for building the same system for multiple target platforms. The implementation details are taken care of by target platform specific templates. The templates are applied to the user models then generating concrete platform-specific artifacts (running code, documentation, database schema, configuration files).  Differently from Java (even if Martin Fowler says so), MDA does not promote another platform. What it does is to promote a clear separation between problem domain concerns and implementation concerns (as covered before here in the inaugural series entitled “Where we are coming from“).
The benefits of this separation are many: from unprecedented levels of reuse to better opportunities for work specialization. I plan to cover these benefits in detail on future posts.
RC



UML modes and tools
rafael.chaves — Sun, 13 May 2007 06:37:30 +0000
On his bliki, Martin Fowler eloquently describes the three different modes in which UML  can be used: UML as sketch, UML as blueprint and UML as programming language. Let’s revisit the different modes from the perspective of tools for the job.
UML as sketch
Description: In this mode, UML is essentially a tool for conceiving and communicating ideas between team members. As such, there is no need for completeness or validity of the object models, and actually any information not essential for communicating the idea at hand is intentionally omitted for conciseness and clarity. UML as sketch is increasingly popular, even at shops where model-driven development is considered an abomination.
Tools for the job: developers don’t need special tools for using UML as a sketching tool, paper and pen or a whiteboard are great. The only flaws are when you would like to archive a drawing or send it to others by email. In that case, Visio (or any other generic diagram editor) is a common choice. Another less known option is Whiteboard Photo, that allows you to take a snapshot of your hand drawings (on a whiteboard or on paper) and have them automatically translated into great looking clean 2-D charts.
UML as blueprint
Description: in this mode, the focus is on having UML models used as an input to the implementation phase, and thus need to be valid and complete from the point of view of structure. Behavioral aspects are described in textual form (such as in use case descriptions) or by means of diagrams depicting scenarios (such as sequence or collaboration diagrams) and are inherently informally and incompletely described. The models can be submitted as input to code generation but the generated code has to be enhanced by hand to cover the behavioral aspects.
Tools for the job: generic tools won’t cut it here - you will need diagram editing tools that support all (or most) of UML diagrams, and (if you are taking the code generation route) persist your models in a format that your code generation tools can understand. Most UML tools out there support (or intend to support) this.
The TextUML Toolkit we provide supports this mode too. Your class diagrams are fully verified, and are persisted using a standard format.
UML as programming language
Description: In this mode, UML models must be complete both structurally and behaviorally as they must be simulatable and serve as input to code generation (by the way, Fowler really misses the point when he argues that a graphical language such as UML is not appropriate for fine grained behavior specification - who said UML is graphical anyway?).
Tools for the job:  there are only a few tools currently in the market that support this mode, they tend to target embedded software development, and I bet you will not find how much they cost on their websites unless you call them.
Corcova Libra will support this, and when made available will visibly sport a reasonably fair price on our web site. Also, Libra will aim at mainstream business application developers, instead of focusing on specific vertical markets.
Conclusion
UML as sketch is cool and useful, but from the point of view of software engineering (our focus here) is meaningless.
UML as blueprint is increasingly practiced in shops where (partial) code generation has been adopted. It has benefits over writing the entire code by hand, but it still requires all the interesting code to be written manually, and there are a lot of issues with that.
Finally, UML as programming language (in other words, full blown model-driven development) is the most interesting of the three modes, even if there is a lot of skepticism and misinformation towards it. I will talk about that in an upcoming post.
RC



Graphical notation in the TextUML Toolkit
rafael.chaves — Sun, 06 May 2007 23:07:08 +0000
Even though a textual notation such as TextUML is much more productive when creating UML models, the graphical notation is still better for a high-level overview. So, for the next milestone of the TextUML Toolkit, the main feature planned is a model visualizer using the conventional graphical notation of UML.
The first option considered in implementing that feature was the UML2 Tools project, part of the Eclipse.org Model Development Tools project. UML2 Tools supports viewing and editing most of UML diagram types, and works seamlessly with models created using UML2 and EMF, which the TextUML Toolkit already uses, and that is great. However, it also requires GEF and GMF, what is bad because it significantly increases the download size for the TextUML Tookit (currently at 31MB), already high for the value it currently provides. Also, from some initial experimentation, it seems to be very computation and/or memory intensive. Because of that, it was decided a more lightweight alternative should be found, even more so if you consider interactivity and support for diagrams other than the class diagram are very low on our list.
Enter Graphviz and UMLGraph
Graphviz is an awesome tool for graph visualization. Graphviz takes simple text files (in the dot notation) describing the graph structure and produces great looking diagrams.
However, Graphviz is very generic, and does not know anything about the UML notation. That is when UMLGraph comes into play. UMLGraph produces dot files that generate OMG compliant UML diagrams (like the ones showing here).
So the direction is to adopt Graphviz and UMLGraph into a lightweight, non-interactive graphical viewer for UML class diagrams. We don’t dismiss having a more powerful graphical viewer (and editor) in the future, probably based on the UML2 Tools project, but the focus now is on simplicity.
There are two difficulties into adopting Graphviz and UMLGraph though:

Graphviz is a native standalone tool, not a Java API
UMLGraph, as a Java doclet, supports only one input representation: Java source with Javadoc comments

Turns out the first obstacle can be easily overcome by wrapping the Graphviz binaries into platform-specific fragments and providing a simple Java API on top of it.
The second obstacle is a bit trickier though. UMLGraph ties the usage of the doclet API into the generation of output in dot form. Breaking that coupling requires a non-trivial refactoring effort. I have been talking to UMLGraph author Diomidis Spinellis and he is keen on the decoupling, and that is the route we are going to take.
Would you like to see what it looks like? Make sure to check out the M2 milestone coming out in mid-June.
RC



TextUML Toolkit as a single download
rafael.chaves — Thu, 03 May 2007 16:53:12 +0000
It has been suggested that it is often the case that non-Java developers are not familiar with Eclipse-based products. Thus, we have made available to Windows users a single-click download option containing only the essential plug-ins from the basic Eclipse platform, EMF and UML2, plus the TextUML Toolkit itself.  Check out the download page.
Users will still have to make sure they have Java 5 or later installed. The ZIP file has 31MB, so if you are familiar with Eclipse, we appreciate if you get the platform, EMF and UML2 from Eclipse.org to keep our hosting costs under control.
Thanks for the feedback, and keep the suggestions coming!
 RC



A website and the first release!
rafael.chaves — Wed, 02 May 2007 07:28:36 +0000
There hasn’t been a post here for a while, but there is a good reason for that: we are glad to announce that we now have an actual web site (go see for yourself) and have simultaneously made the first public release! TextUML Toolkit 1.0 M1 is the first milestone of the tool we have developed for creating UML models in a way that is more natural to hard-core developers. If you want to know more, go read the overview, download the tool and try out the tutorial.
After a long period of silence, I almost pity that I have somehow crammed too many great news on a single post…
RC 



Where we are coming from - Part III
rafael.chaves — Sun, 15 Apr 2007 17:57:25 +0000
(This is the third and last installment in this series. If you haven’t done it yet, read the first and second installments before you proceed)
Let’s start by recalling the main points we wanted to make in the previous posts. In summary, we should strive for addressing concerns as independently as possible (points #1 and #2), and that depending on the dimension (point #3) the concern lives in we should deploy the most appropriate languages and skills for the job (point #4 and #5). The benefits are countless across many areas such as productivity, handling of changes in requirements, reuse, and work specialization. But how to achieve that?
Libra comes to the rescue
Corcova Libra (codename) is our yet to be released tool that supports our vision of how software development should be done. Libra artifacts are models and templates. Problem domain concerns are addressed in a platform-independent way in the form of executable UML models. Implementation-technology concerns are addressed in templates using one of the supported template languages.
Since the platform-independent models are fully complete (from the point of view of business requirements), they can be tried, tested and debugged, even before a target platform is chosen. And when the implementation-aware templates are applied to the platform-independent models, the result is platform-specific code that fully addresses all concerns, be them in the problem-domain or implementation technology dimension.
Libra is not the first product to follow this approach, but is the first that aims to bring the benefits of executable models and full code generation to the masses of application developers.
This is the last post of a series that aimed at explaining what problem we set out to fix. We hope you enjoyed it. We sure were vague on technical details, which we plan to unveil as we release the first publicly available version. If you want to know about any news on the development of Libra, this is the place to watch. If you don’t like to use feed readers, you can also send us an e-mail, and we will let you know whenever a new post is available  (we promise not to spam you, and you can opt-out at any time).



Where we are coming from - Part II
rafael.chaves — Sat, 07 Apr 2007 23:07:21 +0000
(This is the second installment in a series of posts that explains what we think is wrong with the current state of affairs in the mainstream business application development industry, and how we plan to fix it. If you haven’t done it yet, read the first post first)
We finished the first post of this series by stating it was essential to acknowledge the fact that concerns belong to one of two primary dimensions, namely the problem domain dimension or the implementation technology dimension.
The reason for that is that these dimensions impose a set of common characteristics shared by all concerns they are home to. That suggests that we should need different tools when addressing concerns in different dimensions.
Point #4: when addressing a concern, we should use tools that are appropriate for concerns in its dimension.
But is that true? And what are tools appropriate for concerns in the problem domain dimension, or for concerns in the technology dimension? To answer these questions, we need to look deeper to understand the differences between the two primary dimensions.

change rate: concerns in the problem domain dimension change as often as the business requirements change, and that depends on the application and the problem domain. Concerns in the implementation technology dimension change only when a new target platform is to be supported, or a new kind of implementation artifact must be created, or a new implementation strategy (for the technology in use) is chosen. Comparatively, concerns in this dimension are more stable than concerns in the problem domain dimension.
 abstraction level: since concerns in the problem domain dimension can be addressed in a way that is completely independent from implementation details, they can be dealt with at a high abstraction level. Conversely, concerns in the implementation technology dimension are closely tied to the implementation platform and thus have a lower level of abstraction. Trying to address concerns on those two dimensions using the same abstraction level (for instance, by using the same programming language) is less than optimal, and it is bound to favor one dimension at expense of the other (think of an accounting application in C or an operating system in COBOL).
reusability: artifacts created to address concerns in the problem domain dimension are reusable across target platforms and implementation strategies. Artifacts addressing implementation-related concerns are reusable across problem domains. Thus, the languages and methods for addressing concerns in the problem domain dimension should be technology obsolescence-proof, whereas languages and methods for addressing implementation technology concerns are free to harness the power of the technologies they are related to, while remaining agnostic to problem domains.
skills required: developers addressing implementation technology concerns must be deeply familiar with the target platform and must know the best practices for the particular set of technologies chosen, no knowledge of the problem domain being required. On the other hand, people addressing concerns in the problem domain dimension must have good analysis skills and understand the problem domain they are working on - little to no knowledge of the implementation platform is required. They are not exempt though of having good object orientation design skills and a decent proficiency on specifying algorithms using imperative programming. It is seldom the case that a person that is knowledgeable on the problem domain is also an expert at some target platform, so being able to address concerns in different dimensions in a compartmentalized way opens great opportunities for work specialization.

Point #5: Concerns in the problem domain and implementation technology dimensions differ in many fundamental aspects, and thus you need different languages, methods and skills to address them. 
It should be needless to say that this is the model of software development in what we believe. Languages and methods with the appropriate abstraction level for higher expressiveness and power. Problem domain related artifacts that are obsolescence-proof.  Reuse nirvana by completely separating concerns across dimensions. Optimal productivity and job satisfaction through specialization of work across concern dimensions.
All this will be possible only if you can truly address problem domain and implementation related concerns completely independently from one another.
We are building the tools that will allow you to do that. Want to know how? Stay tuned for the next installment in this series of posts. Want to see it with your own eyes and help us make a great product? Send us an e-mail, introduce yourself and tell us how you would like to help.



Where we are coming from - Part I
rafael.chaves — Sun, 01 Apr 2007 03:57:07 +0000
(This is the first installment in a series of posts that will explain what we think is wrong with the current state of affairs in the mainstream business application development industry, and how we plan to fix it)
One term that often appears in a conversation between two developers deciding how to better write a piece of code is “separation of concerns”. But what is a concern and why is separating concerns so important? And even more, why is it being discussed here?
A concern is any basic responsibility a software system has to address. A software system has to deal with many different concerns as it bears many different responsibilities. Basically, a system is made of a collection of composition units or modules (functions, classes, methods, components etc) created to collectively address all of the different concerns imposed by requirements.
But every concern leaves its imprint on the system being developed, in the form of changes or additions to the code. The more places a concern leaves its imprint on, the harder it is to adapt the system due to a change in requirements. The reason is twofold: if the code dealing with a given concern is scattered throughout multiple modules, it is hard to figure out exactly what different places in the source code need to be changed; and if a typical module handles many different concerns at once, it is hard to tell apart code that deals with one concern from code that deals with another.
Point #1: the more independently concerns are dealt with, the easier it is to evolve the code when requirements change.


Ideally, every single concern should map to a single composition unit. If a concern ceases to exist, you delete the corresponding composition unit. If a new concern needs to be taken into account, you just create a new composition unit to deal with it, and no other part of the system is affected. But life is not pretty like that. In practice, there is actually a good deal of interaction between different concerns. So even though maintenance-wise it is better that different concerns are dealt with as independently as possible, it is still required for the system to run correctly that some level of coordination take place between parts of the code addressing different concerns.
Point #2: however, some sort of coordination between code dealing with different concerns is often required.
OK, so far it has been pretty much all common sense, as up to now, we were just trying to level the playing field. But one thing that is not quite common sense yet is the notion that every concern inhabits one of two completely orthogonal dimensions.
One of the dimensions, the dominating one, is home to concerns related to requirements originating from the problem domain. Let’s call it the problem domain dimension. These concerns can be completely understood and dealt with regardless the implementation language or target platform. The richer your problem domain is, the more concerns will inhabit the problem domain dimension.
The second dimension, which we like to call the implementation technology dimension, is also essential, but concerns in this dimension have more of an additive nature. Concerns in this dimension are originated from requirements related to the implementation space, and bear no relationship whatsoever to concepts in the problem domain.
(Are there more dimensions other than the two discussed here? Probably. But pragmatically, we believe that a clear distinction between problem domain and implementation related concerns goes a long way and is the first step we must take.)
Point #3: concerns inhabit one of two dimensions, either the problem domain dimension or the implementation technology dimension.
One important benefit of acknowledging this is that we can now understand that a dimension imposes a common set of characteristics to all concerns inhabiting it. That has several implications, from a much higher degree of reusability to interesting opportunities for work specialization.
But let’s leave that to the next installment. Meanwhile, feel free to comment or ask any questions, just as usual.



The road ahead of us
rafael.chaves — Fri, 23 Mar 2007 22:47:33 +0000
Thanks for checking us out. We are busy working hard on a tool that will bring  software development productivity to a whole new level. At some point this summer, we will release a full fledged model-driven development tool, with support for model execution and complete code generation.
Before that, as a preview, we plan to release one of its components as a standalone product. It is a UML authoring tool that presents a hybrid textual/graphical notation. Our hunch is that even hardcore hackers will want to use it.
Stay tuned!

declaration	Java	TextUML
single-valued	`Client c`	`c:Client`
multi-valued	`Collection c`	`c:Client[*]`
multi-valued	`Client[] c`	`c:Client[*]`
ordered	`List c`	`c:Client[*]{ordered}`
unique	`Set c`	`c:Client[*]{unique}`

id		summary
171		ClassCastException if an interface has an implements section
172		ClassCastException if tagged value does not match property’s type
173		NPE for invalid input
174		resource leak in TextUML Source Viewer
175		EmptyStackException whn multiple duplicate named elements exist
176		CoreException when cleaning up file that is use on Windows
177		show annotations for packages in source viewer
178		decouple TextUML source editor from the EclipseGraphviz viewer

Ticket	Summary
49	prevent creation of duplicated symbols
102	NPE trying to set value for stereotype property
143	declare a built-in update site for the textuml toolkit
145	project creation wizard issues
164	Support nested packages in TextUMLRenderer
165	Unexpected exception while compiling - java.lang.IllegalStateException: deresolve relative URI
166	spurious empty null.uml or base_profile.uml files being created
168	integrate a code generator
169	constant literal assignment is broken