200604240937105.html

软件工程的红包书

<P>　　Use Case具有一个基本事件流（可称为"理想路径"）、多个例外流，包括：<BR>　　　　基本变化<BR>　　　　特殊情况<BR>　　　　处理错误情况的异常事件流 </P>
<P><STRONG>五、Use Case 说明书</STRONG></P>
<P>　　Use Case 说明书应包括以下内容：<BR>　　　　功能描述<BR>　　　　可用性<BR>　　　　可靠性<BR>　　　　性能<BR>　　　　可支持性<BR>　　　　设计约束</P>
<P><STRONG>六、Use Cases将做成多大？</STRONG></P>
<P>　　试图决定Use Case的大小是一个很有趣的话题，处理这件事的一个方法是将Use Case的大小跟它的意图和范围关联起来，对于一个真正大的范围来说，一个Use Case并不要在一个系统中处理那么多，但这些系统都用于同一商业领域，称为<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200604231354525.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200604231354525.html'" tppabs="http://www.itisedu.com/phrase/200604231354525.html" target="_new">Business Use Case</a>，它把整个公司看作一个黑盒和Actor关于公司目标的说明。这些Business Use Case的场景不允许假定任何公司内部的结构，一个客户将向公司下一个定单而不是客户服务部门。 </P>
<P>　　对于系统发展而言，Use Case的范围限制一个单一的系统，这是Use Cases最通常的形式，我们称之为System Use Case，它把整个系统看作是一个黑盒，它不指定任何内部结构并且仅受限于问题域的语言描述。</P>
<P>　　Use Cases的另一范围是设计子系统和系统内部<a href="200603302222545.html" tppabs="http://www.itisedu.com/phrase/200603302222545.html" target="_new">组件</a>的，称为Implementation Use Cases，它把组件看作一个黑盒，并且这些Actors是区分它的成员。例如：可能会用Implementation Use Cases去说明应用系统中email组件的需求。 </P>
<P>　　给出了这些分类，关于Use Case的大小话题变得容易了，设计这些项的范围来调整整个大小。<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200604231414405.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200604231414405.html'" tppabs="http://www.itisedu.com/phrase/200604231414405.html" target="_new">帮助系统</a>设计者，每个Use Case只描述没有大的分支的行为的单个线索。违背这个规定，Use Case看起来通常是不准确的或含糊的，作为测试说明的资源和参考，它也是很难使用的。 </P>
<P><STRONG>七、Use Cases的说明</STRONG> </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Use Cases的好处是一些情节能用不同程度的正规化的文字说明。每个情节涉及Use Cases中单一的途径，细节是条件组。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 不正规的文本描述也能使用，不过当条件较多和可能失败的情况下它们很难跟随下去。开始试图理解需求时，不正规的叙述风格也是非常有用的，然而随着Use Cases的进展，使用更加正规的机制去说明Use Cases才是有用的。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 下面是客户对Use Case“下定单”的粗略概略： </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; “确定客户，找出需要的并且仓库里还有的物品并检查客户信用额是否够用” </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 结构化叙述的格式已经被证明是非常有效的。这个格式所做的事是描述每一个情节的行为者：目标语句对顺序的叙述。在这个顺序中，每一个行为者：目标的语句对都假设前一个的目标是成功的，右面是一个简单的范例： </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Use Cases认为我们正在设计的系统是一个单一的黑盒，根本没有任何内部结构被记录下来，并且它被认为是一个情节产生的目的及对应单一的行为者（Actor）。这些Use Cases没有表示任何关于系统内部的东东，只是表示系统将达到什么样的目标及由什么（人或其它系统）操作和负责。 </P>
<P align=center><IMG src="2006327181715343.gif" tppabs="http://www.itisedu.com/manage/Upload/image/2006327181715343.gif" border=0></P>
<P><BR><STRONG>八、Use Cases使需求有利于回顾</STRONG> </P>
<P>　　Use Cases已经得到越来越广泛的应用，它与其它需求捕获技术相比，它成功的原因在于：<BR>　　　　1