<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: UML Statecharts and Documenting Business Rules</title>
	<atom:link href="http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/</link>
	<description>Software product success.</description>
	<lastBuildDate>Tue, 07 Sep 2010 01:40:54 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/comment-page-1/#comment-331782</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Wed, 19 Mar 2008 00:42:57 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/#comment-331782</guid>
		<description>Hey Demon, welcome to Tyner Blain and thanks for commenting! 

You&#039;re exactly right - while the diagram shows the transition from start to save, the table is missing it.

Thanks VERY much for pointing that out both to me and future readers of this article.  Please keep finding things like this to help with other articles!</description>
		<content:encoded><![CDATA[<p>Hey Demon, welcome to Tyner Blain and thanks for commenting! </p>
<p>You&#8217;re exactly right &#8211; while the diagram shows the transition from start to save, the table is missing it.</p>
<p>Thanks VERY much for pointing that out both to me and future readers of this article.  Please keep finding things like this to help with other articles!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: The Demon</title>
		<link>http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/comment-page-1/#comment-330820</link>
		<dc:creator>The Demon</dc:creator>
		<pubDate>Mon, 17 Mar 2008 15:41:01 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/#comment-330820</guid>
		<description>Hi Everyone, 

I love this site, it&#039;s a great reference site and when having a &quot;moment&quot; I often flick on to get a reality check. Keep up the good work. 

Anyway, a quick comment on the Transition Table, just a little thing. 

I always include a transition from the &quot;Start&quot; state (black blob) to the first &quot;real state&quot;. In your example that would be from the start state to &quot;Save&quot;. There must be rules regarding whether someone can save or not? They need to have registered or have a valid, open account? They need to have at least one item in their cart, etc. 

Just a wee thing but if anyone is using this as a reference, as I do, then it&#039;s important. Happy to be corrected if anyone disagrees.

The Demon, Sunny Scotland.</description>
		<content:encoded><![CDATA[<p>Hi Everyone, </p>
<p>I love this site, it&#8217;s a great reference site and when having a &#8220;moment&#8221; I often flick on to get a reality check. Keep up the good work. </p>
<p>Anyway, a quick comment on the Transition Table, just a little thing. </p>
<p>I always include a transition from the &#8220;Start&#8221; state (black blob) to the first &#8220;real state&#8221;. In your example that would be from the start state to &#8220;Save&#8221;. There must be rules regarding whether someone can save or not? They need to have registered or have a valid, open account? They need to have at least one item in their cart, etc. </p>
<p>Just a wee thing but if anyone is using this as a reference, as I do, then it&#8217;s important. Happy to be corrected if anyone disagrees.</p>
<p>The Demon, Sunny Scotland.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: links for 2007-03-25 &#171; D e J a M e S e R</title>
		<link>http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/comment-page-1/#comment-83119</link>
		<dc:creator>links for 2007-03-25 &#171; D e J a M e S e R</dc:creator>
		<pubDate>Sun, 25 Mar 2007 15:37:06 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/#comment-83119</guid>
		<description>[...] UML Statecharts and Documenting Business Rules &#124; Business Analysis &#124; Product Management &#124; Software Requirements &#124; Tyner Blain In yesterday’s article we compared use cases and UML statecharts as tools for discovering business rules. James Taylor asked a question about how we would document those rules, and then followed up my comment response with an article about business rule (tags: uml) [...]</description>
		<content:encoded><![CDATA[<p>[...] UML Statecharts and Documenting Business Rules | Business Analysis | Product Management | Software Requirements | Tyner Blain In yesterday’s article we compared use cases and UML statecharts as tools for discovering business rules. James Taylor asked a question about how we would document those rules, and then followed up my comment response with an article about business rule (tags: uml) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/comment-page-1/#comment-82809</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Sat, 24 Mar 2007 16:25:46 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/#comment-82809</guid>
		<description>Thanks James, I completely agree - hiding requirements is just a bad idea.

Anyone else out there have a different approach that works for them?  

Ben mentioned &quot;Provision&quot; in the comments on the other Use Case v Statechart article.</description>
		<content:encoded><![CDATA[<p>Thanks James, I completely agree &#8211; hiding requirements is just a bad idea.</p>
<p>Anyone else out there have a different approach that works for them?  </p>
<p>Ben mentioned &#8220;Provision&#8221; in the comments on the other Use Case v Statechart article.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Taylor</title>
		<link>http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/comment-page-1/#comment-82511</link>
		<dc:creator>James Taylor</dc:creator>
		<pubDate>Fri, 23 Mar 2007 18:42:39 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/03/22/statecharts-and-business-rules/#comment-82511</guid>
		<description>Nice post. At the requirements stage, the most important thing is to call out the rules separately (as you note), not bury them. People are successful with all sorts of approaches to writing them but they must be managed explicitly.</description>
		<content:encoded><![CDATA[<p>Nice post. At the requirements stage, the most important thing is to call out the rules separately (as you note), not bury them. People are successful with all sorts of approaches to writing them but they must be managed explicitly.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
