<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: A reader&#8217;s &#8220;Thoughts about TextUML&#8221;</title>
	<atom:link href="http://abstratt.com/blog/2007/12/18/a-readers-thoughts-about-textuml/feed/" rel="self" type="application/rss+xml" />
	<link>http://abstratt.com/blog/2007/12/18/a-readers-thoughts-about-textuml/</link>
	<description>A company obsessed with one single goal: stopping people from writing so much code</description>
	<pubDate>Wed, 08 Sep 2010 18:33:26 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: rchaves</title>
		<link>http://abstratt.com/blog/2007/12/18/a-readers-thoughts-about-textuml/#comment-65</link>
		<dc:creator>rchaves</dc:creator>
		<pubDate>Sun, 30 Dec 2007 19:36:39 +0000</pubDate>
		<guid isPermaLink="false">http://abstratt.com/blog/2007/12/18/a-readers-thoughts-about-textuml/#comment-65</guid>
		<description>Hi Andreas,

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</description>
		<content:encoded><![CDATA[<p>Hi Andreas,</p>
<p>I see now, thanks for clarifying. That is a good point.</p>
<p>As I said above, the focus for the TextUML Toolkit&#8217;s is code generation, requiring completely defined models (all typed elements must declare a type), and thus it is not ideal for sketching.</p>
<p>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 &#8220;picture&#8221; 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 &#8220;formal&#8221; 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).</p>
<p>Cheers,</p>
<p>Rafael</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andreas</title>
		<link>http://abstratt.com/blog/2007/12/18/a-readers-thoughts-about-textuml/#comment-64</link>
		<dc:creator>Andreas</dc:creator>
		<pubDate>Sun, 30 Dec 2007 13:30:35 +0000</pubDate>
		<guid isPermaLink="false">http://abstratt.com/blog/2007/12/18/a-readers-thoughts-about-textuml/#comment-64</guid>
		<description>Hello all,

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 &#38; best regards,
Andreas</description>
		<content:encoded><![CDATA[<p>Hello all,</p>
<p>seems as if I finally have been confused somewhat in my first comment.<br />
While I wrote<br />
&#8220;I don’t think I would achieve the same effect with a *graphical* notation (only).&#8221;<br />
I actually meant the opposite<br />
&#8220;I don’t think I would achieve the same effect with a *textual* notation (only).&#8221;</p>
<p>Sorry &amp; best regards,<br />
Andreas</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rchaves</title>
		<link>http://abstratt.com/blog/2007/12/18/a-readers-thoughts-about-textuml/#comment-63</link>
		<dc:creator>rchaves</dc:creator>
		<pubDate>Wed, 19 Dec 2007 08:25:47 +0000</pubDate>
		<guid isPermaLink="false">http://abstratt.com/blog/2007/12/18/a-readers-thoughts-about-textuml/#comment-63</guid>
		<description>Hey 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 &lt;a href="http://www.eclipse.org/gmf/" rel="nofollow"&gt;GMF&lt;/a&gt; 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 &lt;a href="http://www.eclipse.org/proposals/imp/" rel="nofollow"&gt;IMP&lt;/a&gt; project.

Another project following the same approach (for Ecore-based models) is &lt;a href="http://wiki.eclipse.org/Emfatic" rel="nofollow"&gt;Emfatic&lt;/a&gt;.

Cheers,

Rafael</description>
		<content:encoded><![CDATA[<p>Hey Andreas,</p>
<p>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: <a href="http://abstratt.com/blog/2007/05/12/uml-modes-and-tools/" rel="nofollow">http://abstratt.com/blog/2007/05/12/uml-modes-and-tools/</a></p>
<p>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 <a href="http://www.eclipse.org/gmf/" rel="nofollow">GMF</a> is for graphical modeling). The TextUML Toolkit is just a concrete implementation of a specific textual notation for UML.</p>
<p>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 <a href="http://www.eclipse.org/proposals/imp/" rel="nofollow">IMP</a> project.</p>
<p>Another project following the same approach (for Ecore-based models) is <a href="http://wiki.eclipse.org/Emfatic" rel="nofollow">Emfatic</a>.</p>
<p>Cheers,</p>
<p>Rafael</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andreas</title>
		<link>http://abstratt.com/blog/2007/12/18/a-readers-thoughts-about-textuml/#comment-66</link>
		<dc:creator>Andreas</dc:creator>
		<pubDate>Tue, 18 Dec 2007 21:26:46 +0000</pubDate>
		<guid isPermaLink="false">http://abstratt.com/blog/2007/12/18/a-readers-thoughts-about-textuml/#comment-66</guid>
		<description>Hello 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</description>
		<content:encoded><![CDATA[<p>Hello Rafael,</p>
<p>thanks for your appreciation.<br />
There&#8217;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&#8217;t think I would achieve the same effect with a graphical notation (only).<br />
Anyway, it seems as if you are not alone:<br />
<a href="http://www.eclipse.org/proposals/tmf/" rel="nofollow">http://www.eclipse.org/proposals/tmf/</a><br />
(I was not aware of this until recently)</p>
<p>Best regards,<br />
Andreas</p>
]]></content:encoded>
	</item>
</channel>
</rss>
