资源描述：
《如何编写用例文档》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。
1、如何进行用例建模呢，这里主要分解为三步： 1.识别参与者(ACTOR) 参与者作为同系统交互的所有事物，它可以是人也可以是其它系统或硬件等。它不是系统的组成部分，是独立于系统而客观存在的。其实在确定参与者时可以采用提问的方式来找出来，如谁是系统的主要用户？谁从系统获得信息等等。而作为BLOG这种软件，这里为了便于分析，将参与者确定为用户(或会员和作者等，一但确定之后，下面的用例描述就要这样使用它们)，同时为了不与域模型中的用户和用户列表有任何模糊上的关联。这里将域模型中的用户和用户列表更名为用户信息，用户信息列表。而另一个ACTOR就是系统管理员了，而先前域模型中的
2、系统管理员则相应更名为系统管理员信息。 2.确定用例。 确定用例时ICONIX方法认为“首先要确定尽可能多的用例，然后不断地编写和改进描述这些用例的文本，在这一过程中，您将发现新的用例和通用情况”。而确定用例的一个最重要的原则就是它必须同用户手册中的材料密切相关，每个用户和用户指南的各部分之间的关系必须是显而易见的。从手册出发的原因就是要求开发人员“必须从用户角度来分析和设计系统”。因为手册内容一般都非常庞大(相关模版在网上获取)，动不动就几十甚至几百页。而从中归纳出文档所需要的内容必定也是非常繁琐的，但这一步又非常必要。因为篇幅所限，又因为担心大家偏离本文的思想，所以这
3、里也只有跳过了，大家完全可以在网上找到相关的信息来填充这一空白。另外识别用例也可以采用提问方式，如每个参与者的任务？系统需要何种输入输出？等（详见“系统分析师设计指南之统一建模语言”）。 在有些书中会使用合并需求（主要是功能性需求，非功能性需求可附加到用例描述中）来获得用例，而进行合并操作的原则也就是生成“可见结果”的过程(这一步因为所做的事情过于繁杂，本文就不再涉略了)，并完成用例命名和绘制用例图。从我个人来看，这两者(ICONIX方法和其它方法)是相辅相成，并无冲突。 限于篇幅直接将初步确定并整理出来的用例列出来[采用动词(短语)-名词(短语)形式]： 注册用户
4、(UC01),登陆系统(UC02),发表文章(UC03),编辑文章(UC04),删除文章(UC05),浏览评论(UC07),删除评论(UC08),浏览留言(UC09),删除留言(UC10),添加链接(UC11),编辑链接(UC12),删除链接(UC13),上传文件(UC14),删除文件(UC15),管理文件类型(UC16),编辑签名(UC17),编辑个人信息(UC18),编辑BLOG基本信息(UC19),(管理员)审核用户(UC20),创建俱乐部[或群](UC21)等。 (管理员的基它功能操作这里只作为次要需求被过滤掉了，希望大家能够理解。从而将注意力放在ICONIX方法和用例的
5、设计分析上为宜) 而相关的Blog系统用例图如下(为下面的用例文档细化作准备): 5.1-9,,services,andmakethecitymoreattractive,strengtheningpublictransportinvestment,establishedasthebackboneoftheurbanrailtransitmulti-level,multi-functionalpublictransportsystem,thusprotectingtheregionalpositionandachieve 其实要指出一个笔者以前犯过的小错误，相信也是很多朋
6、友不知不觉也会犯的错误，就是如何布置用例的层次。ICONIX方法建议使用包来展现这种层次结构，举个例子就是管理文章(里面include几个子用例如添加，编辑，删除文章等)，ICONIX会用一个包来包含这几个用例，并写上包的名称，然后再在包中绘出相应的子图。这样做的原因主要是： 为开发小组之间分配工作提供了逻辑边界，一条可遵循的规则是每个包对应于用户手册的一间或者至少一大节。我这里直接用一个大范围用例图的做法主要是为了方便说明整个系统的全貌，使大家对系统用例有一个整体认识而已。希望大家在实际工作中（用例数量很大的情况下）要进行权衡。 另外有三种"用例关系"的定义需要在这里简短介
7、绍一下： include（包含）: 指一个用例的行为包含了另外一个用例的行为，这是一种特殊的依赖关系。也就是"hasa"的关 系。见上图中的（管理文章和发表，编辑以及删除文章的关系） generation（泛化）: 指一个用例（子用例）继承另外一个用例（父用例）的行为和含义，而该用例在继承了另外一个 用例的行为和含义的基本上，还可以增加新的行为和含义以覆盖原有用例的行为和含义。比如
