如何编写用例文档.doc

如何进行用例建模呢，这里主要分解为三步：1.识别参与者(ACTOR)参与者作为同系统交互的所有事物，它可以是人也可以是其它系统或硬件等它不是系统的组成部分，是独立于系统而客观存在的其实在确定参与者时可以采用提问的方式来找出来，如谁是系统的主要用户？谁从系统获得信息等等而作为 BLOG 这种软件，这里为了便于分析，将参与者确定为用户(或会员和作者等，一但确定之后，下面的用例描述就要这样使用它们)，同时为了不与域模型中的用户和用户列表有任何模糊上的关联这里将域模型中的用户和用户列表更名为用户信息，用户信息列表而另一个 ACTOR 就是系统管理员了，而先前域模型中的系统管理员则相应更名为系统管理员信息2.确定用例确定用例时 ICONIX 方法认为 “首先要确定尽可能多的用例，然后不断地编写和改进描述这些用例的文本，在这一过程中，您将发现新的用例和通用情况”而确定用例的一个最重要的原则就是它必须同用户手册中的材料密切相关，每个用户和用户指南的各部分之间的关系必须是显而易见的从手册出发的原因就是要求开发人员“必须从用户角度来分析和设计系统”因为手册内容一般都非常庞大(相关模版在网上获取) ，动不动就几十甚至几百页。

而从中归纳出文档所需要的内容必定也是非常繁琐的，但这一步又非常必要因为篇幅所限，又因为担心大家偏离本文的思想，所以这里也只有跳过了，大家完全可以在网上找到相关的信息来填充这一空白另外识别用例也可以采用提问方式，如每个参与者的任务？系统需要何种输入输出？等（详见“系统分析师设计指南之统一建模语言”） 在有些书中会使用合并需求（主要是功能性需求，非功能性需求可附加到用例描述中）来获得用例，而进行合并操作的原则也就是生成“可见结果”的过程 (这一步因为所做的事情过于繁杂，本文就不再涉略了 )，并完成用例命名和绘制用例图从我个人来看，这两者(ICONIX 方法和其它方法)是相辅相成，并无冲突限于篇幅直接将初步确定并整理出来的用例列出来[ 采用动词 (短语)-名词(短语)形式]：注册用户(UC01),登陆系统(UC02), 发表文章(UC03),编辑文章(UC04),删除文章(UC05),浏览评论(UC07),删除评论(UC08),浏览留言(UC09),删除留言(UC10),添加链接(UC11),编辑链接(UC12),删除链接(UC13),上传文件(UC14),删除文件(UC15),管理文件类型(UC16),编辑签名(UC17),编辑个人信息 (UC18),编辑 BLOG 基本信息 (UC19),(管理员)审核用户(UC20),创建俱乐部[或群 ](UC21)等。

管理员的基它功能操作这里只作为次要需求被过滤掉了，希望大家能够理解从而将注意力放在 ICONIX 方法和用例的设计分析上为宜)而相关的 Blog 系统用例图如下(为下面的用例文档细化作准备): 其实要指出一个笔者以前犯过的小错误，相信也是很多朋友不知不觉也会犯的错误，就是如何布置用例的层次ICONIX 方法建议使用包来展现这种层次结构，举个例子就是管理文章(里面 include 几个子用例如添加，编辑，删除文章等)，ICONIX 会用一个包来包含这几个用例，并写上包的名称，然后再在包中绘出相应的子图这样做的原因主要是：为开发小组之间分配工作提供了逻辑边界，一条可遵循的规则是每个包对应于用户手册的一间或者至少一大节我这里直接用一个大范围用例图的做法主要是为了方便说明整个系统的全貌，使大家对系统用例有一个整体认识而已希望大家在实际工作中（用例数量很大的情况下）要进行权衡另外有三种"用例关系"的定义需要在这里简短介绍一下：include（包含）:指一个用例的行为包含了另外一个用例的行为，这是一种特殊的依赖关系也就是"has a"的关系见上图中的（管理文章和发表，编辑以及删除文章的关系）generation（泛化）:指一个用例（子用例）继承另外一个用例（父用例）的行为和含义，而该用例在继承了另外一个用例的行为和含义的基本上，还可以增加新的行为和含义以覆盖原有用例的行为和含义。

比如“按作者进行 BLOG 检索”和“按内容进行 BLOG 检索”与“BLOG 检索之间”的关系这种关系可以用"is a"来表示extend（扩展）:类似于泛化(generation)关系, 不过对扩展的用例有更多的限制如一个用例明显地混合了两种或以上的不同场景，即可能发生多种事情而我们可以断定将这个用例分为一个主用例和一个或多个辅用例描这可能更加清晰 好了，有了用例之后就该细化用例文本了3.细化用例文本首先先拿用户注册开刀假设用户文本如下:用例名称：注册用户(UC01)用例文档：基本流程：用户输入其姓名，密码(两次)，EMAIL 地址，然后点击注册按钮系统在确认该用户提交信息有效之后，使用当前数据初始用户相关信息并记录到用户信息列表中然后系统提示用户要等待系统管理员进行审核分支流程：如果用户没有提供姓名，系统将显示一条错误信息，来告之用户输入姓名如果用户提供的 EMAIL 地址格式不正确，系统将显示一条错误信息, 要求用户输入正确的 EMAIL地址如果用户两次输入的密码不同，系统将显示一条错误信息,提示用户两次密码要一致如果用户提交的用户名已在用户信息列表中存在，系统将告诉用户并建议用户使用其它的用户名。

可能大家看到之后，有些人会认为这一步过于简单了，因为在不少介绍用例的书里当讲到这块都会长篇大论一番，并且关于如何描述用例子的基本和分支流程有些 UML 书籍可能会提供一些可参考的规则如：1.主语名称，语义要易于理解2.要让读者明确参与者在控制还是系统在控制而作为 ICONIX 方法中的用例模版，它与其它的 UML 方法或许多大师级所推荐使用的用例模版有所不同它用的是 1040EZ 式模版，换言之它所主要包括的是基本流程 (基本事件流)和分支流程 (扩展事件流)它不像复杂的模版中还要有前置，后置条件，非功能性需求，扩展点和优先级等内容该方法认为那些东西不仅会分散注意力同时也会浪费宝贵的时间作为 ICONIX 它所推荐的做法是 :1.创建简结的用例模版(其中标有“基本流程”和“分支流程”)2.提出“将发生什么” 的问题，然后进行基本流程3.提出“然后将如何”，并不断提出这样的问题，直到你获得有关基本流程的所有细节4.提出“否则将如何”，是否还有其它情况? are you sure? 不断提出这些问题，直到记录下来大量分支流程为止总之这么做不求完美无缺，而是考虑用户可能执行的操作大家可以参考这些规则来看上面的" 注册用户"看看是否还有什么别的启发 :)另外需要要强调的就是用例文本基本形式: 名词-动词-名词“同时这一过程中如果发现新的对象后，还应对（问题）域模型进行更新，来加深对以前发现对象的理解”。

比如我们将在下一个用例中发现新的对象)下面说一个用例就是“管理文章 ”用例的三个子用例，大家在这里看到它包含三个子用例，分别是发表，编辑和删除文章，而有关包含(include) 上面已做过说明它自身的三个子用例是系统的主要功能用例文档： 发表文章(UC03)基本流程：用户在发表文章页面中输入文章标题，所属分类(自定义或系统类型)，文章内容，是否使用摘要，是否发表（或放入草稿箱）等信息之后点击提交按钮，系统在确认该篇文章提交信息有效之后，使用当前数据添加到文章列表中分支流程：如果用户没有文章标题，系统将显示一条错误信息，告之用户输入文章标题如果用户提供文章内容，系统将显示一条错误信息, 要求用户输入文章内容如果用户采用摘要形式发布，但却没有录入摘要内容时，系统将显示一条错误信息, 要求用户输入摘要内容如果用户在未完成当前文章内容时要跳转到其它页面，系统将显示一条警告信息，提示用户所编辑的内容将会丢失如果用户提交的文章标题已在文章列表中存在，系统将告诉用户并建议用户使用其它的标题编辑文章 (UC04)基本流程：用户在编辑文章页面中修改文章标题，所属分类（自定义或系统类型） ，文章内容，是否使用摘要，是否发表（或放入草稿箱）等信息之后点击提交按钮，系统在确认该篇文章提交信息有效之后，使用当前数据修改文章列表中的相应文章信息。

分支流程：如果用户没有文章标题，系统将显示一条错误信息，告之用户输入文章标题如果用户没有输入文章内容，系统将显示一条错误信息, 告之用户输入文章内容如果用户采用摘要形式发布，但却没有录入摘要内容时，系统将显示一条错误信息, 要求用户输入摘要内容如果用户在未完成当前文章内容时要跳转到其它页面，系统将显示一条警告信息，提示用户所编辑的内容将会丢失如果用户提交的文章标题已在文章列表中存在，系统将告诉用户并建议用户使用其它的标题删除文章 (UC05)基本流程：用户在文章列表页面上点击相应文章标题左侧的"删除"按钮后，系统提示用户是否删除该标题的文章，当用户确认后则删除文章列表中的相应文章内容信息分支流程：如果用户在提示框中点击"取消删除"按钮，则系统将不会进行任何操作并将页面重定向到文章列表页在上面三个用例文本中都提到了一个新的对象就是文章列表，而这个对象是我在上一篇文章中提到但没加入到域模型中，而这里因为从需求中得到了系统确定需要这个对象，所以需要更新一下相应的域模型了:)下面要说的一个用例就是" 管理文件类型"在聊这个用例之前有些问题需要先解释一下，就是这个用例本身是否需要分解为三个子用例（添加，编辑，删除）会更为合适? 但是如果这样做的话，就会使得用例的数目多添加三个。

如果说一遇到这种情况就去如此分解的话，可能会使用例的数目过于庞大这其实也是一个需要注意的问题，在许多用例驱动的书中都肯定会不可避免的谈到这一问题，即“用例的分解粒度”，因为分解过度会显著提高复杂度，而过低则有可能违背用例的“可见价值结果”的原则如果说“管理 BLOG 系统”这个用例就是一个太大的用例，根本看不出什么对用户有价值结果而“输入用户名”这个用例又太小，把它当成一个步骤会更合适，这个“度”上的把握最终还是要从系统（软件）的整体来衡量才是根本 聊了这么一大堆再回到当前的" 管理文件类型"这一用例上，在我看来，它本身可能是因为用户（文档）比较简单所以就把三个所谓的子用例做了一下合并，变成一个用例当然这也是仁者见仁，智者见智，不是完全绝对化的，还希望大家自行斟酌，多提意见:)管理文件类型(UC16)基本流程：系统管理员在"添加文件类型"表单中(位于"文件类型列表"页面)输入文件类型名称（如 RAR，JPEG等） ，类型描述，最大上传尺寸，上传路径名称等信息之后点击提交按钮，系统在确认该信息有效之后，使用当前数据添加到文件类型列表中系统管理员在文件类型列表页面中的相关类型上点击删除按钮，系统提示是否删除该文件类型，在管理员确认后则从文件类型列表中删除相应的记录。

系统管理员在编辑文件类型页面中修改相应类型名称，类型描述，最大上传尺寸, 以及相应路径后点击更新按钮，系统在确认该信息有效之后，使用当前数据修改类型列表中的相应文件类型信息分支流程：如果用户在添加和编辑表单中没有输入类型名称，最大上传尺寸，上传路径名称时系统提示输入相关信息如果用户提交的类型名称已在文件类型列表中存在，系统将告诉管理员并建议管理员使用其它的名称如果用户在提示框中点击取消删除按钮，则系统将不会进行任何操作并将页面重定向到" 管理文件类型"页面。