Archive for the ‘TextUML Toolkit’ Category

Moving forward again

Thursday, June 19th, 2008

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

Wednesday, June 18th, 2008

(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

Wednesday, June 11th, 2008

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:

eg-pref-page-small.png

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:

eg-pref-page-demo-1-small.png

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

eg-pref-page-demo-0-small.png

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

Friday, June 6th, 2008

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

Wednesday, June 4th, 2008

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

Wednesday, June 4th, 2008

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

30-day challenge: the road to TextUML Toolkit 1.0

Friday, May 30th, 2008

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

Friday, May 16th, 2008

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!

Tuesday, May 6th, 2008

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.

“Why we write code and don’t just draw diagrams”

Monday, May 5th, 2008

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

Monday, April 28th, 2008

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 April’s VIJUG meeting

Sunday, April 13th, 2008

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

Wednesday, March 26th, 2008

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

Monday, March 3rd, 2008

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!

Thursday, February 28th, 2008

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:

click for a full screenshot

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

Thursday, February 7th, 2008

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

Sunday, January 27th, 2008

I just added a brand new FAQ section to the web site. It was long overdue.

Here is the first batch of questions:

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

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

A reader’s “Thoughts about TextUML”

Tuesday, December 18th, 2007

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:

  1. the presentation notation and the persistence format are completely unrelated concerns (exactly, see my previous comment on this).
  2. 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)
  3. 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.

  1. 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.
  2. 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.
  3. 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

Saturday, December 8th, 2007

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.

UML 101 with TextUML: multiplicity (or [*])

Saturday, November 17th, 2007

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<Client> c c:Client[*]
Client[] c
ordered List<Client> c c:Client[*]{ordered}
unique Set<client> c c:Client[*]{unique}

There are few interesting differences though:

  1. in UML, it is the typed element itself that defines multiplicity, and not the type
  2. c:Client, c:Client[1] and c:Client[1,1] are all equivalent
  3. c:Client[*], c:Client[1,*] are equivalent
  4. 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.
  5. 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:

  1. 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
  2. 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

Thursday, November 1st, 2007

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<T>
    attribute prop1 : T;
    operation op11(par1 : T);
end;

class Fred
    attribute attr1 : Bar<Foo>;
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.

TextUML Toolkit M2a - Java 5 users please read

Saturday, September 8th, 2007

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

Thursday, September 6th, 2007

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 <profile-name>;

stereotype <stereotype-name> extends <metaclass-1 [,...metaclass-n]…]
[<property-1>; [... 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 <<persistent>> stereotype:

profile business_apps;

import uml;

stereotype persistent extends Class
end;

end.

Or operations could be marked as <<transactional>>, 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 <<Session>> stereotype for session beans. The<<Session>> 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 <<persistent>> stereotype to the Bank class, and the <<transactional>> 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.

TextUML Toolkit 1.0 M2 is available!

Sunday, September 2nd, 2007

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:
ubuntu-first-small.jpg

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

Wednesday, August 29th, 2007

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.

textuml-toolkit-10m2-small.jpg

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)

Thursday, August 23rd, 2007

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:

Graphical viewer showing image files

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

Graphical viewer showing DOT files

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

Graphical viewer showing UML model

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

Friday, August 3rd, 2007

Just finished a raw implementation of a viewer for GraphViz dot files. Here is a screenshot:

EclipseGraphviz in action

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

RC

Graphviz support in Eclipse

Monday, July 23rd, 2007

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

Friday, June 1st, 2007

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.

UML modes and tools

Saturday, May 12th, 2007

In 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

Sunday, May 6th, 2007

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:

  1. Graphviz is a native standalone tool, not a Java API
  2. 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

Thursday, May 3rd, 2007

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!

Wednesday, May 2nd, 2007

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

The road ahead of us

Friday, March 23rd, 2007

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!