走出用例图误区

来自：http://blog.csdn.net/mochi_lq/article/details/6318752

    uml初学者，大部分都是从认识用例图开始。记得我刚学uml的时候，导师就再三跟我强调，uml只是一门工具，不是为了画图而画图。这句话听来并不难理解，但真要在实际项目中领悟参透还是需要一段时日的。它反应在各种需求建模的细节中。
    uml用例图也并未很难画，各种用例的间的关系也不是很难理解。对于初学者来说，很容易把重点放到uml用例图上，而忽视了用例文本（用例规格说明）的编写。高手提取几个用例会很轻松，但要编写严格、干净、逻辑性强的用例文本却非易事。所以，用例文本的编写很容易看出一个分析/设计人员的水准。
    用例图可以直观地展现需求中的所有用例、参与者、系统边界，以及它们之间的关系，但这还不足以表达需求分析所要求表达的内容。用例图必须辅之以用例说明，才能完整清楚地表达。用例模型是需求分析阶段的主要成果，因此它担负的职责繁重。用例模型必须做到以下要求：  
1、语言的互通。用例模型采用的语言必须达到，既能让业务人员看懂，以便给予业务确认，又能让技术人员看懂，以便进行日后的设计开发。因此，用例模型的描述必须是对业务需求最平实的表述，站在业务人员的角度说事儿，不能参杂过多的技术语言。同时，又要站在技术的角度进行分析，详细清楚地表述各个功能的操作流程，并不能使用过于专业的业务术语，或者对必要的业务术语进行解释，让技术人员看懂。
2、清晰准确。用例模型必须清晰准确地表达每一个业务需求，因此我们在建立用例模型的时候，必须明确每一个术语，每一段表述，不能存在二义性。
3、最全面和详尽的业务需求。用例模型必须从各个角度，全面地反映客户对系统的期望。用例模型对业务需求把握得越全面和详尽，项目出现偏差和风险的几率就越小。这要求我们进行分析时，各个角度都要分析到。
要做到以上几点其实并不容易，所幸的是，用例说明为我们提供了一个良好的范例。用例说明在用例模型中的作用，甚至超过了用例图。寥寥几页的用例图，需要数十页甚至上百页的用例说明来描述。用例说明需要按照一定的格式，对所有用例图中的所有用例进行描述，如果有必要，还要对参与者、系统边界和部分术语进行描述。下面我们来看看用例说明是怎样编写的。
按照用例分析的特点，用例说明也应当从粗到细依次进行编写。首先是对整个系统进行概述，编写总用例图的说明，然后依次编写各个支用例图的说明。在编写每个用例图时，首先贴上该用例图，然后为每个用例编写说明。
下面就是从主用例图开始，依次对所有用例图进行说明。在对每个用例图进行说明时，先贴出用例图，然后为每个用例编写说明。在这部分，每个用例的说明可以按照如下格式编写：
用例标识：用例的编号。
用例名称：根据用例表达的功能而取的简短明了的名称。用例命名其实是有讲究的，即必须是一个动词短语或句子，而不是一个名词短语，通常建议为一个动宾短语（如：提取存款），一个被动句（如：发票填报），或者一个主谓句（如：用户提款）。用例的命名表现了用例的特点，即它代表的是参与者的操作，是一个动作。尽量不要取 “××管理”或“维护××”，因为这个动作应当是一个非常明确的动作，而“××管理”代表的是插入、修改、删除等一系列动作，操作就变得不明确了。
应用范围：就是要设计的系统。
用例类型：“用户目标”还是“子功能”，即是用户需要操作的目标功能，还是从“用户目标”中提取出来的“子功能”。“用户目标”应当至少有一个参与者，来驱动它完成相关操作，而“子功能”通常没有，因为它往往是被系统所驱动。
用例描述：对该用例的功能定义、要实现的业务需求，以及谁（参与者）如何进行使用进行描述。同时，这部分还可以整体概述实现业务需求的主要流程，以及与其它用例、其它外部系统的关系。
参与者：列出与该用例相关的参与者，包括进行操作的人（角色）和相关的外部系统。
涉众利益：关注该用例的人对该用例的要求，它往往是非功能需求，或者是功能需求中的一些常常为我们所忽视的细节。如客户要求在填写一些表单的时候能够快速进行查找，而另一些系统管理员希望提高可维护性（虽然他们可能不是该用例的参与者）。编写涉众利益应当按照如下格式：使用数字编写序号，而每个涉众利益应当书写为“谁期望怎么样”。
前置条件：在触发该用例相关操作前必须达到的条件。
事件流：是用例说明中最重要的部分，它详细描述了该用例可能出现的所有流程。
基本流程：又称为“主流程”或“主成功场景”，它描述的是该用例以最正常的方式流转，并且最终获得成功的流程。基本流程在编写时，应当通过数字，对流程中的每一步进行编号
扩展流程：又称为“替代流程”、“分支流程”或“交替场景”，它描述的是基本流程在流转过程中可能出现的所有分支。扩展流程在编写时，通常使用“数字+小写字母”对扩展流程进行编号。数字代表该扩展流程是在基本流程的哪一步发生分支的。如果是任意位置满足某条件就会发生分支，则使用“*”代替。小写字母代表该扩展流程是本用例中的第几个扩展流程。扩展流程编号的后面应当描述进入该扩展流程的条件。最后，和基本流程一样，通过数字编号，详细描述该扩展流程的整个流程。如果在扩展流程中还会出现分支，则如上递归地描述该扩展流程的扩展流程
异常流程：故名思意，它是对该用例的所有基本流程和扩展流程可能出现的所有异常情况及其处理流程的描述。与扩展流程一样，异常流程首先通过“数字+小写字母”进行编号，描述出现异常的条件。如果是任意位置都可能满足异常条件，则使用“*”代替数字。随后，编写出处理该异常的整个流程。按照以上步骤，罗列出所有可能出现的异常情况。
后置条件：又称为“成功保证”，就是执行基本流程获得成功以后所达到的状态（条件）。后置条件往往体现的是执行该用例的最终目的。
非功能需求：我们可以把它们简称为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。
补充规格说明书：该用例对应的补充规格说明书。
除此之外，用例说明还可以包括其它内容。比如，该用例是用于查询数据或展现一个表格，则应当画出数据的格式或表格的样式，并详细标注数据间的运算关系；如果客户对该用例有其它硬件或技术要求，可增加“技术与数据变元”项。
在编写这部分说明的时候，还有一个非常关键的地方值得注意。当我们在编写事件流时，如果发现多个用例都出现相同或相似的流程，并且功能相对独立时，应当考虑将它提取出来单独形成一个用例。如果是这样，在原用例的这个地方只需说明在执行某个步骤时进入哪个用例就可以了，不用再描述这部分流程。如果原用例在基本流程中调用这个用例，则原用例包含这个用例；如果原用例在扩展流程中调用这个用例，则这个用例是对原用例的扩展。
另外，异常流程也是一个非常重要的内容。过去我们在分析阶段没有考虑异常处理的情况，以致在开发阶段不知道怎样处理才能让客户满意。但值得提醒的是，这里的异常是站在业务层面的异常，如：“用户不能提供单据号”，或“用户未领取通知单”。而那些技术层面的异常不应当出现在这里，如“数据库连接失败”等。
编写用例说明的建议
按照过去RUP的设计思路，填写用例说明的时候，所有的项目都必须填写清楚完整，这是一个繁琐而令人沮丧的工作。然后，敏捷开发的思想出来了，我们都解脱了。敏捷开发的一个重要思想就是：我们只做我们需要做的事情，千万不要去做不需要做的事情（这也就是它称之为的“过度设计”）。用例说明只有几个项目是必填的：用例名称、用例描述、参与者（有的用例可能没有参与者，但必须写“无”而不能不写）、基本流程，其它都是可选项。另一个重要的思想就是迭代，需求分析是一个逐渐推进的过程，因此千万不要想到把用例说明写得一步到位。在这个问题上，大师给我们了建议。Craig Larman在他的《UML和模式应用》中这样描述，他说用例的编写有三种常用形式：摘要、非正式和详述。
摘要，简洁的一段式概要，通常用于主成功场景，在早期需求分析中为快速了解主题和范围而使用，范例：
处理销售：顾客携带所购商品到达收银台。收银员使用POS系统记录每件商品。系统连续显示累计金额，并逐行显示明细。顾客输入支付信息，系统对支付信息进行验证和记录。系统最终显示交易成功。
非正式的，就是以一种非正式的段落格式，描述各个场景。它用于在需求分析逐渐深入的过程中使用。范例：
处理退货
主成功场景：
顾客携带商品到收银台退货。收银员使用POS系统记录每件商品……
交替场景：
如果客户之前使用信用卡付款，而其信用卡账户退还交易被拒，则告知顾客并使用现金退货
如果在系统中未查找到该商品的标识码，则提示收银员并建议手工输入标识码。
……
详述，就是前面详述的完整格式，它主要用于需求分析后期以及最终需求确认的时候。即使采用详述的方式，也没有必要每个用例都写出每个项目。需要写的时候才写，不需要就不要写。即使需要写的内容，也是在需求分析逐渐深入过程中逐渐完成的。
用例说明将过去需求规格书面向过程进行需求分析的方式，转变成面向对象的分析方式，即需求中的所有过程都被封装在了一个个用例中。同时，用例说明又给我我们一个模板，让我们照着这个模板进行需求分析，避免了我们在分析过程中可能遗漏用于信息的问题。另外，用例说明从一开始就进入了OOD/A分析，将可复用的、相对独立的功能进行提取、封装，避免了过去程序设计才开始OOD/A分析所造成的许多设计规划先天不足的问题。总之，用例说明已经不单纯是对原需求的简单描述，而是带着面向对象的设计思想在进行需求描述。