Also to be done:

• publishing the new build (RC3/1.0)
• publishing the Acceleo modules
• writing an article on how to generate code for the Pet Store example

Feel good about your decision, it’s better to be cautious than flippant when releasing a product people are expected to pay for. Like yourself I’ve not gone to release, though technically finished I have a lot of code polish I am not confortable shipping without doing first.

The TextUML Toolkit relies on Eclipse UML2, an open source API for reading and manipulating UML models. Eclipse UML2 persists models in XMI, which is the standard XML-based interchange format for UML. Most UML tools in the market support XMI, including (to my surprise) Visio.

Unfortunately, there are quite a few different flavors of XMI implementations, causing tools to be incompatible with each other. I haven’t tried accessing from the TextUML Toolkit a UML model exported from Visio, but I would be surprised if it works.

The TextUML Toolkit is supposed to be compatible with any of the tools listed here, as they also rely on Eclipse UML2 for importing and/or exporting UML models.

Good luck to you too!

Rafael

Best of luck with your application. I’m looking forward to seeing how you go with this. Do you think you’ll offer any support for GUI design tools such as Visio in the future?

Cheers,

Mike

who’s the other one?
Just kidding…
Anyway. I’m WATCHING you.
Feel the pressure?

Good luck & have fun,
Andreas

Please read this post on the UMLforum newsgroup:

http://groups.google.com/group/UMLforum/msg/e55e565ad753721d

I am big believer in incremental design. UML does not preclude that, actually even facilitates that. Yes, tools that generate code once that you must maintain by hand from there on are a pain. But executable modeling-based tools don’t have that caveat because the model is the code.

Executable modeling is still new and not exposed by any of the mainstream UML tools, and thus is not well known. But I am working towards changing that…
BTW, thanks for the link!

EMF is here and can show its usefulness today, and that is great. But we have a long way ahead of us, and a structure-centric approach won’t take us far enough. But it is a good step in the right direction. I think I read people are considering a model-based approach for e4. That is awesome, and much/all of the credit for making the Eclipse Platform developers even consider the idea certainly goes to the Ed Merks Framework.
“Make it real, pragmatic, and valuable, and you’ve made it matter. In other words, don’t just say it matters, make it matter…”

Awesome advice! I think I am working on that!

Yes, UML is huge. It grew from a unified notation that combined the pre-existing OMT, Booch and OOSE approaches to a multi-paradigm executable modeling language. It does suffer from trying to be everything to everybody.

But nobody says you must use all of its features. There are many uses of UML, and the trick is in recognizing what is relevant and what must be ignored.

“MDA as such is interesting but I think at this point, it is very clear it is only usable in very specific and stable domains. “

I would say more than 50% of the applications out there involve implementing simple business logic and database-based persistence. That is clearly an excellent target for MDD. Why hasn’t it picked up yet? My bet is that the tool providers that support feature-rich MDD are just not interested in that market if they cannot charge 100K+ for their tool suite (as they do in the telecom and embedded industry).

people like Martin Fowler point out that UML might not be the best tool for this particular job even

I truly admire Martin Fowler for his many contributions, but I strongly believe he is completely off (and as are other luminaries, such as Dave “Bedarra” Thomas) when it comes to UML and MDD.

“One also has to question whether model-driven development itself is the right paradigm”

True. I would not want to write an OS, or Eclipse itself, using UML and MDD. But most of the code being currently being written in Java out there (i.e. business applications) is built at the wrong level of abstraction, and this is why even though we have been doing that for decades, we still suck at doing it. Gosh, I think even Cobol was more appropriate than the Java-based solutions currently in use.

“Start over, if it’s not tool late and make a real executable modeling language.”

If a better executable modeling language is born, I will be happy to move to it. Must-have requirements: high-level of abstraction, not owned by a company, backed by a solid metamodel, syntax agnostic, solid open source reference implementation. Oh, I guess it will help if I can translate back and forth to UML.

Hey, I think I just described UML.

I asked someone a few months ago, what are people doing with these fancy UML tools? Don’t they want to generate code? The answer was that although there is code generation support, mostly people use the tools to draw pretty pictures. Of course if the quality of the code being generated is poor, and worse yet, if it doesn’t support iterative development, the pictures about about the most valuable thing you get.

It makes me sad and helps remind me to focus on practical things that matter to real developers. It’s quite easy to map UML to Ecore and thereby to extract significant value from the investment. It’s also easy to go in the other direction too, if someone is in need of gratuitous gratification…

That said, I would like to see more studies on how UML is used in industry. My current understanding is that it has an optimistic 40% usage rate (mostly for communication, I would think).

See http://amazinnggg.blogspot.com/2006/11/uml-usage.html

In any case, I personally have grave concerns about formalisms such as UML and XML Schema that seem to be complex in a way that is far beyond the mental capacity of the average human being. That being said, I believe simplicity is an illusion that hides intrinsic complexity behind intuition and deep understanding.

My personal ambition is to ensure that EMF’s pragmatic approach to model driven development solves real every day problems so that it can be used to build simple applications or even monstrously complex things like UML and XML Schema. Rather than argue from up on a soapbox about the virtues MDD, I’d rather spend my time addressing limitations that impede real programmers in their daily lives; although I do love a good strong soapbox. Make it real, pragmatic, and valuable, and you’ve made it matter. In other words, don’t just say it matters, make it matter…

MDA as such is interesting but I think at this point, it is very clear it is only usable in very specific and stable domains. Additionally people like Martin Fowler point out that UML might not be the best tool for this particular job even.

To be fair, I think UML was doomed the day the OMG got involved. I think OMG has a long track record proving that design by committee leads to bloated, over engineered compromises.

And this comes from a guy who spent a good 8 years of his career trying to make modeling matter and gave up along with many a colleague. UML is crap, the tools are even worse. Start over, if it’s not tool late and make a real executable modeling language. Oh yeah, we had that with ObjecTime Developer. Thanks, Rational! (ok, I’m a little bitter

Thanks for your comments, glad to hear from you again. You make interesting points, as usual.

> let’s not forget that the UML defines 13 diagram types
> and TextUML only addresses the class diagram
> (static structure).

True. However, even though I can’t think of a single UML diagram type for which a textual notation could not at least do the job, supporting them all is not the goal of the TextUML Toolkit.

The goal is to support enough features of UML to enable basic (elaboration-style) model-driven development - described in the post on UML modes as UML as blueprint .

So, yes, the usefulness of the TextUML Toolkit is limited to what you can do if you restrict yourself to modeling structure only. But many (most?) of the code generation tools in the market have the same limitation, and they are quite useful.

> What about designing and/or documenting complex
> interactions with sequence diagrams?
> A control flow with activity diagrams?
> A state machine with a state machine diagram?
> A system architecture with a deployment diagram?

My interest in UML is primarily as a language for model-driven development. That, for starters, excludes diagrams such as use case, sequence, object and communication/collaboration diagrams. Those basically support the UML mode known as UML as draft.

And even though some other diagrams can be useful in the context of MDD (deployment and package, for instance), they are not really essential.

The only diagrams I think are really important in the context of model-driven development are the class, activity and state diagrams. Actually, depending on what/how you are building, you can get by with the first (which is the core diagram in UML) and one of the other two.

> In addition, the static structure of the code is usually
> the “easy part”. The hard part are the dynamics and
> interactions.

Totally agree!

> So - a bit evil minded - I could say that
> TextUML only addresses the parts of a software
> system that cause only a fraction of the overall effort
> of creating a complex software system.

You are right if we take into account what you can see in the TextUML Toolkit. But in a larger product I have been working on for quite a while now (I called it Corcova in the past), which is the sole reason the TextUML Toolkit product exists, you can model activities using (action language-style) TextUML and can do cool things that are only possible if you go beyond the structural aspects (in the spirit of UML as programming language, mentioned in that same post.

I plan to write in more detail about this sometime this summer, hopefully along with a cool demo! But if you have more questions/comments, I will be glad to exchange more ideas on the subject.

let’s not forget that the UML defines 13 diagram types and TextUML only addresses the class diagram (static structure).
What about designing and/or documenting complex interactions with sequence diagrams?
A control flow with activity diagrams?
A state machine with a state machine diagram?
A system architecture with a deployment diagram?
While the static structure of a software system is relatively easy to grasp (anyway, the first thing I do when looking at new code is run Doxygen on it and look at the nice diagrams generated from the code) the dynamic aspects are deeply hidden in code and they can be very hard to discover. A current diagram with the right abstraction level can give you more insight than weeks of reading code.
In addition, the static structure of the code is usually the “easy part”. The hard part are the dynamics and interactions. So - a bit evil minded - I could say that TextUML only addresses the parts of a software system that cause only a fraction of the overall effort of creating a complex software system.

Best regards,
Andreas

http://www.infoq.com/news/2007/11/pictures-or-words

And watch for the next milestone (M4, which will be available by the end of the month), for which the goal is to be complete and solid enough so it is ready for beta testing. It will also integrate a 3rd-party code generator (Acceleo) and a complete example of code generation. Stay tuned!

Rafael

Nice progress. Keep up the good work!

I see now, thanks for clarifying. That is a good point.

As I said above, the focus for the TextUML Toolkit’s is code generation, requiring completely defined models (all typed elements must declare a type), and thus it is not ideal for sketching.

But it does not have to be like that. A textual notation could allow incomplete syntax, and thus be appropriate for sketching. I agree that when sketching, we usually are in “picture” mode. However, your sketch of a UML model might eventually evolve into a more complete version suitable for code generation. In that case, if you are a user that bought the idea of textual notation for “formal” modeling, my guess is that you would be fine with using the textual notation while sketching as well (granted, relying heavily on the automatic diagram rendering feature).

Cheers,

Rafael

seems as if I finally have been confused somewhat in my first comment.
While I wrote
“I don’t think I would achieve the same effect with a *graphical* notation (only).”
I actually meant the opposite
“I don’t think I would achieve the same effect with a *textual* notation (only).”

Sorry & best regards,
Andreas

Maybe surprisingly to you, the TextUML Toolkit would not be a good tool for sketching as it requires well formed models. Please see this post for more on this subject: http://abstratt.com/blog/2007/05/12/uml-modes-and-tools/

Thanks for the pointer to the TMF proposal. That one is much more ambitious as it is a framework for building textual notations for modeling, for multiple metamodels (basically being for textual modeling what GMF is for graphical modeling). The TextUML Toolkit is just a concrete implementation of a specific textual notation for UML.

When/if TMF becomes a reality, the TextUML Toolkit could in theory be retrofitted to be based on TMF. The same considerations are true for the IMP project.

Another project following the same approach (for Ecore-based models) is Emfatic.

Cheers,

Rafael

thanks for your appreciation.
There’s another point I forgot in my posting: in early design phases sketching diagrams works great for me to (iteratively) get a clearer picture of a systems design. I don’t think I would achieve the same effect with a graphical notation (only).
Anyway, it seems as if you are not alone:
http://www.eclipse.org/proposals/tmf/
(I was not aware of this until recently)

Best regards,
Andreas

since Rafael asked me here are some of my thoughts on the topic:
http://www.empowertec.de/blog/2007/12/10/thoughts-about-textuml/
Executive summary:
From the point of view of a tool vendor, using text to manipulate the structural aspects of a UML model seems not the right approach to me.
(As I understand Rafael plans to make TextUML part of a commercial product).

Best regards,
Andreas

> I would have really liked to attend that event, but
> the ferry ride from Victoria to Vancouver was a little
> too much for me on Thursday.

Yeah, I am in Victoria too, and the ferry sure is a hassle, but it was really worth it. If you have where to stay, that helps keeping the costs down too. Next time, propose to present - it helps with the motivation. And if that is not enough, think of the free beer.
I completely agree with you on the graphical notation being better for showing relationships, and that the textual notation is better for detailing the classes. Going even further, I believe the graphical notation is completely unsuitable for detailing behavior, such as describing activities. You are bound to use text for that.

Thank you guys for all the interesting opinions and ideas. With all this material, writing that post on textual vs. graphical notations (and internal representation vs. user-facing notations) should be a breeze now.

> Being able to go between the two would be key, because than
> I could at least produce graphics for people who need a
> graphical model

Oh yeah, I am with you on that one - this seems to be one of the recurring conclusions every time I see the textual vs. graphical debate.

The toolkit has a graphical viewer that is very immature/raw right now, but should look much better when I adopt UMLGraph as the rendering engine. But it will be just a viewer, not an editor.

For a graphical editor, users will have to look elsewhere. But given that the models created by TextUML are serialized using UML2, there are a few choices of graphical tools now (such as Eclipse UML2 Tools) and there will be more in the future as UML2 gains more traction. This is not supported yet, but I plan to have an editor for TextUML that will read and save UML models natively instead of saving the source code as-is and generating the UML model as the object code, as it is now. That would allow different team members to collaborate (read/modify) on the same models using their notation of choice.

1) multiple user oriented notations: one notation will be better than another for different people, or at different tasks. There is no point in forcing everyone to use the same notation, for all tasks. Why not use the one the best suits your personal preferences, or that is more appropriate for the task at hand?

2) decoupling between serialization format and user oriented notation: the serialization format is just that, a way a program chooses to represent information in a unidimensional way. The main requirement here is to be able to easily parse that representation, regardless the environment you are. My take is that XML is the best thing we have in that sense (XMI incompatibilities aside). In my opinion, it would not make sense to expect people to be writing TextUML (or Emfatic) parsers just to be able to load a UML (or EMF) model into memory. Machine readability and human readability are conflicting forces, there is no way around that. Tools have needs that are very different from people and as such my take is that trying to use the same syntax for serialization and as a user-facing notation is not the right thing to do, as it will favor one kind audience at the expense of the other for no good reasons, given that the semantics is all that matters.

Ed, I think the text vs. graphical notation comes down to how you want to exploit our cognitive abilities. Humans are very good an interpreting relationships between elements when presented graphically, however, in the case of UML I think we are often more concerned with the specification of the classes rather than the relationships between them.

I still miss Vancouver a lot but I’ll be there to visit family after the coming week’s board meetings…

> my experience is that time and time again, folks who
> start out saying they don’t need it now, later end up
> needing it for one of the many useful capabilities it provides

When I say that there are many cases where the EMF Runtime is not appropriate, I am talking more of cases where it is not applicable/possible due to some sort of constraint. These are often technical reasons: managed objects (EJBs), constrained environments (J2ME), non-Java apps, non-code artifacts, etc. Not to mention cases where the requirements dictate what technology is allowed to be used by the application (common if you are selling to the government).

> EMF4Net proposal (http://wiki.eclipse.org/EMF4Net_Proposal)
> demonstrate that the runtime is useful even in other languages.

Yes, I am pretty sure the same design would work for other languages. That for sure will expand the range of applications. Still, as in the case of Java, for other languages you will also have cases where it is not possible/applicable to use an EMF-style runtime.

> In any case, folks can use EMF to generate non-EMF artifacts
> and it would be relatively simple to generate POJOs.

Here you are talking about using EMF-based models and writing templates yourself, right? This is exactly how I use EMF (most of the time), and I don’t think you guys should worry about this scenario other than keeping ECore as versatile as it is today. Providing generation of POJO code out of the box should be out of scope for EMF itself, although it might make sense to cover things like that in EMFT projects. The needs for code generation when the target is not the EMF runtime are so diverse that I think most users would want to have their own templates anyway.

> In any case, the community has great value to me,
> so I’m inclined to listen when it speaks. That doesn’t
> mean I can do everything it asks.

For me, there is nothing else to be done other than preserving and evolving Ecore as an independently usable tool. Sometimes I notice features that are missing and realize that UML has. Instead of expecting more from Ecore, in those cases I think adopting the full-fledged UML2 is the best option.

> The fact that a powerful core modeling technology that can
> bootstrap itself can be used for unlimited purposes isn’t an
> accident, it’s inherent in the model drive development paradigm.

True. But one can always decide to ignore that and deem everything outside of the initial focus as “unsupported”.

> You really don’t need to worry about us ever doing
> anything to break out clients.

That is great. I was just not sure people using Ecore-based models for targetting anything other than EMF-runtime based Java apps were actually considered clients. I feel much better now. Thanks!

In any case, folks can use EMF to generate non-EMF artifacts and it would be relatively simple to generate POJOs. I’m pretty sure Martin Taal has done that. If there was significant interest in this in the community, as opposed to the occasional negative shopper easily swayed to reconsider their approach, as well as folks willing put their development resource where there mouth is, I certainly would reconsider my position. But to me, things like supporting containment seem important even for POJO. It’s not clear if folks would still want a factory, and interface/implementation split (without which you can’t support multiple inheritance), or just plain old public constructors. Even if someone contributes an implementation, my very small team would end up needing to maintain it, so it’s important folks realize that my position also needs to be guided by wise allocation of resource.

In any case, the community has great value to me, so I’m inclined to listen when it speaks. That doesn’t mean I can do everything it asks. Certainly EMF was designed to implement the full behavior implied by Ecore’s metamodel, which includes bidirectional references and containment so most definitely generating code that supports this via a runtime is EMF’s primary goal. Generating POJOs at this time is not a secondary goal, but is definitely an interesting application for Ecore, as is generating C# code, HTML documentation, or anything else you could possibly imagine. The fact that a powerful core modeling technology that can bootstrap itself can be used for unlimited purposes isn’t an accident, it’s inherent in the model drive development paradigm.

You really don’t need to worry about us ever doing anything to break out clients.

I am not against supporting that usage scenario (annotated Javadoc’d Java code), but that is what I think it should be: a usage scenario. Even if UMLGraph moves to an API style, the current approach still should be supported as one possible input form.

It is a matter of separation of concerns (syntax and semantics are different concerns). Separation of concerns promotes reuse, and I always aim for reuse. High-level textual languages are for humans, not for tools. Different people like different syntaxes, even if the semantics is the same, so if the tool is strongly tied to a specific syntax notation, you are needlessly bound to have people that won’t like the tool because of the language. That does not make sense to me economically and strategically wise.

UML is a great example of that: the semantics are extensively defined, and a graphical notation is proposed based on the semantics. Then, you can have a tool chain that supports UML, and one or more model creation tools that support different input notations.

Another (incidental) reason is that there are plans of covering other UML diagrams in UMLGraph (sequence diagrams are already supported), and you cannot do that with annotated Java code, so another notation is required anyway (UMLGraph uses pic for sequence diagrams).

Thanks for your comments,

Rafael

ok, thanks!
But i don’t get what’s the problem with UmlGraph relying on Java source code. Actually UmlGraph uses just a subset and I see this subset as a domain specific language for describing UML diagrams. So, instead of controlling an object model based on some API the client code emits a piece of source code (*you* should like that :-).
Granted, this may be a bit more cumbersome and provides more potential for runtime errors but in practice it does not stop me using it (We are actually building an application that uses UmlGraph for rendering class diagrams - a UML metamodel viewer). I think it is a tiny implementation detail.
I’d prefer having a version that does not rely on an external binary (the dot program) and a Java installation (our software is .NET based).

Best regards,
Andreas

1) Graphviz integration is part of the TextUML Toolkit since m2.

2) UMLGraph integration is under way and should be ready before the end of the year.

http://abstratt.com/blog/2007/05/06/graphical-notation-in-the-textuml-toolkit/

There are plans of adopting UMLGraph soon, but not before it suffering a significant surgery that will make it more useful in other contexts (UMLGraph currently only supports annotated Javadocs as input). That effort has just started (way later than initially planned). For the next milestone of the TextUML Toolkit (M3), UMLGraph should be the rendering mechanism.

Also, EclipseGraphviz is mainly about rendering graphs using Graphviz in Eclipse. The current UML class diagram rendering in EclipseGraphviz is more an example of a concrete application than anything else.

Thanks for the comments.

I wonder how EclipseGraphviz differs from UmlGraph (http://www.spinellis.gr/sw/umlgraph/)?
NIH syndrome?
SCNR
Best regards,
Andreas

Yes, an update site is planned for before the next milestone. The main reason it was not done yet was that updates are based on features, and the Eclipse UML2 feature required by the TextUML Toolkit also requires the JDT Core feature, which is totally unnecessary in the context of our toolkit. That means someone that has CDT and not JDT would have to install JDT Core before installing the TextUML Toolkit. We plan to fix that by providing a simpler feature that has only the Eclipse UML2 plug-ins we actually need.

That might work, if you think non-interactive visualizations are fine with your audience. I would be very interested in seeing others making use of the existing infrastructure and helping evolving it into a useful but minimalistic graph rendering framework. Right now the only use case pushing its development is visualization of UML models (class diagrams), which is my personal interest.

Be warned though that besides the bundling of Graphviz and the image viewing framework there is very little value in it for non-UML related applications at this point.

Let me know if you have suggestions or ideas. If you feel like contributing code, commit rights are one patch away.

I think I understand what is going on now.

The image viewer is a view, not an editor. Instead of double-clicking the file, you should be able to open it by going Window > Show View > Other… > Other > Image Viewer.

Now that you have the view open, you should be able to see the images by navigating the files on the package explorer, resource navigator or project explorer. Also, there is no special editor for DOT - the Eclipse basic text editor should do it for now.

I committed last night a fix to a bug that prevented Graphviz from working as a deployed plug-in, but if you are running from the source you should not be affected by that problem anyway. Another recent fix made the image viewer aware of files opened in an editor (before it only worked for files selected in one of the views I mentioned above). I should start versioning the repository and making an update site sometime in the near future.

About the issue with the com.abstratt.settings project, that should go away if you defined a path variable named WORKSPACE_ROOT pointing to your workspace directory (Window > Preferences… > General > Workspace > Linked resources > New…).

Let me know if that works for you. Thanks a lot for trying the tool and providing feedback!

Rafael

Nothing shows up in the Error log either. The only issue I have is that when I try to checkout com.abstratt.settings, the following error occurs: “Must specify a URI scheme:WORKSPACE_ROOT/com.abstratt.settings/.settings”. But I don’t think this project is necessary anyway.

This is a neat project, I’d like to give it a shot. We’re interested in converting our custom domain-specific language into DOT to visualize our graphs. The on-the-fly editing is really appealing.