软件方法阅读笔记（三）

 业务建模映射出系统用例的识别方法：在业务序列图中，从外部指向所研究系统的消息可以映射为该系统的用例。  
  识别系统用例的注意事项：
  一、主执行者和辅执行者：主执行者从执行者指向用例，而辅执行者从用例指向执行者，主执行者发起用例的交互，辅执行者在交互过程中被动参与进来。场景：主执行者要执行用例，需要辅执行者的帮忙。
  二、切勿把到辅执行者的箭头误解为数据传送的方向。
  三、主辅执行者是针对某个用例来说的，一个系统在这个用例中充当主执行者，也可以在另一个用例中充当辅执行者。一般说来，辅执行者是人肉系统的情况比较少，更多时候是另一个非人智能系统。
  四、用例是涉众愿意“购买”的、对系统的一种“用法”，只要涉众愿意“购买”，当然是越多越好。
  五、需求是不考虑“复用“的，如果在考虑”复用“，要紧惕自己是不是已经转换到了设计视角来思考问题。
  六、针对不同执行者、不同业务流程，系统提供的价值可大可小，无论大小均是用例。
  七、用例的命名。用例命名采用"动宾结构"，宾语前可以加定语，把一句话的主语砍掉，剩下的可以做用例的名字。  
  常见错误：踏实研究业务流程，做好业务建模，尽量从业务序列图中映射出系统用例，这样的系统用例是不会骗人的。
  一、把步骤当作用例。Include（包含）关系的目的是为了复用在多个用例中重复出现的步骤集合，形状往往是多个大用例Include一个小用例。
  二、CRUD问题。把数据库的各个表名加上新增、检索、修改、删除就得到了用例的名字或者把四种操作合并称为“XX管理”。
  三、玩弄“复用”：用例的执行者不同，背后的涉众利益也有差别，不能简单的合并复用为某一个操作。
  四、多个主执行者指向同一个用例。如果用例图已完成，对于这种错误的修改，可以通过泛化出抽象的执行者或者分成几个不同的用例的方法来修改。后一种更常见。
  五、玩弄”层次“。切勿偷换"研究对象"，也切勿”把愿景当系统功能“。
  六、玩弄”子系统“：用例很多时可以将用例分包，但用例包是在系统的外部对系统功能所做的划分，而子系统则是根据内部部件的耦合和内聚切割得到。
  七：模糊的价值：系统往往无法承诺执行者预期的价值时，则该价值不是执行者的用例。主执行者执行用例时，若是需要辅执行者提供实时的帮助后才能进行，则用例正确，否则用例错误。  
  关于“XX管理”的用例：这种用例无法从业务流程中映射，但系统需要它们来支撑。也只有对于这种支撑的管理基本数据的用例，才用“XX管理”来打扫战场。"XX管理"这样的用例往往是给管理员管理基本数据用的，而且都是千篇一律。
  软件工程的“底层”：怎样才能使这段代码更容易维护和扩展？这段代码达到的功能和性能对涉众意味着什么？

        2). 系统用例规约：也就是以用例方式组织的需求规约，我们需要通过书写用例规约把用例背后封装的各种相关需求表达出来，并用类图展示用例的各项内容。
     用例包含的内容：
     a. 前置条件和后置条件：用例通过前置条件、后置条件以契约的形式表达需求。可以想象成：在满足前置条件的开始，按照说明的路径步骤走，就能达到后置条件。    
        后置条件分类：最小后置和成功后置。最小后置指在用例失败的情况下也要满足的约束，而成功后置指用例成功时系统需要满足的约束。     
        前置、后置条件的要求：
        一、前置条件、后置条件必须是系统能检测的。
        二、前置条件必须是用例开始前系统能检测的。
        三、前置后置条件是约束，不是动作。
        四、前置后置条件要有系统的味道。
        五、登录的问题：登录不是用例，不能从登录扩展出产看订单等功能，扩展的正真意思是分支。正确的做法应该是把登录变成被其他用例包含的被包含用例，在写用例规约的时候发现下单、查单等用例都有登录步骤，为节省工作量把这些形成一个小目标的步骤集合分离出一个只能被其他用例包含的用例。如：会员登录中，加括号的登录表示这是一个被包含用例，他的步骤和约束在另外的地方描述。

        涉众利益的要求：前置条件是起点，后置条件是终点，这中间的最要的内容就是涉众利益，即：某类人担心什么、希望什么，若没有涉众利益很难得到正确的需求。认识到需求由涉众利益的平衡和冲突决定，可以帮助我们直入需求的核心。
        一、如何寻找涉众：定位用例涉众的场景：如果系统的这个用例做不好，谁或者哪个系统会遭殃？谁会担心自己的直接利益受侵害？
            从执行者触发寻找涉众：若果执行者是人，其便为用例涉众。否则，执行者没有利益主张，不算涉众，但是要留意其背后可能的涉众。
     从“上游”寻找涉众：执行者使用系统做某个用例，需要一些资源，这些资源的提供者可能是涉众。
     从“下游”寻找涉众：执行者使用系统做某个用例，会产生后果，这个后果所影响到的人也是涉众。
     从“信息的主人”寻找涉众：用例用到的相关信息所涉及的某些人（也可能其不知道这个系统的存在）的利益受系统好坏的影响。随着策略环境变化、组织需要调整，原有良好的系统确实要改变，这才是真的需求变更。
     从“给涉众排位”寻找主要涉众：涉众排位是否准确，直接影响了需求的内容，开发人员别只盯住了“用户”而忽略了前排涉众。并没有一定的排位准则，只能根据所改进组织的特点归纳总结。
     “亲兄弟，明算账”：在描述涉众利益时，要把不同涉众关注的不同利益体现出来。在列出涉众利益后，在照顾前排涉众利益的同时，也要争取兼顾和平衡其他涉众的利益。涉众利益放在用例规约里可以体现出不同涉众针对不同用例有不同利益的特点。
     “基本路径”：我们需要写出能够平衡各方涉众利益的路径、步骤和补充约束。用例需要有一条基本路径，若干条扩展路径，首先把基本路径单独分离先写出来，因其代表用例核心价值的路径。
         书写路径步骤的要点：
         1.) 按照交互四步曲书写：执行者和系统一个个回合进行交互，直到达成目的。每回合步骤分为两类：请求、回应（有的回合可能没有验证和改变），其中括号表示操作在系统内。
         2.) 使用主动语句理清责任：把动作的责任人放在主语的位置，用Cockburn的话就是“球在哪里”。
         3.) 主语只能是主执行者或系统。写需求时要把系统当作一个黑箱，仅描述它对外提供的功能和性能，而系统如何构造不属于需求描述的范围。
         4.) 使用核心域的概念：路径步骤是功能需求，应该使用核心域的概念来描述，也就是说，要说“人话”。应该避免“技术”、“业务”等名词，而换用“核心域”、“非核心域”来代替。
         5.) 不要涉及交互设计的细节：避免把界面细节带入到需求中。“人有眼镜”不是需求，需求是“人能看”。
             需求的判断标准：需求是问“不这样行吗”，而不是“这样行吗”。需求确实需要写的细，是需要将需求（问题）写的细，而不是将设计（解决方案）写的细。