《软件方法》读书笔记3
改进途径：
一、物流变信息流。为降低流转成本，尽可能把物流变成信息流，在需要物的时候才将信息变成物。
二、改善信息流程。可以依靠引入一个新的系统来达到在多个信息系统之间实现信息传递和协调。
三、封装领域逻辑。通过将人脑中的领域逻辑提炼封装到信息系统中，使人脑得到解放。在绘制业务流程时，非常重要的改进点是：一定要注意画出人脑中的思考逻辑，避免白开水一样的业务流程。前两条改进，系统内部封装逻辑不复杂，效率高，而做到第三条，就可以靠软件的功能就能卖钱。
四、阿布思考法。
改进思路是：1.假设有足够的资源去解决问题，得到一个完美的方案；2.用手上现有的资源去山寨这个完美方案。例如：中国组织最得力的会议是靠人脑组织的全国人民代表大会，做会议软件的话可以山寨一二。
“创新的需求是从观察和思考的汗水中来，不是把拍脑袋闭门造车的所谓‘头脑风暴‘当作调研”。
2-系统建模：与业务建模不同的是研究对象，业务建模的对研究对象是组织，而系统建模的研究对象是系统。
1.画出系统用例图：有了业务建模的铺垫，系统用例实际上以呼之欲出。
1). 系统用例图：
a. 确定系统执行者：系统执行者的定义是在所研究系统外，与该系统发生功能性交互的其他系统。有了前面的业务建模，就不需要头脑风暴了，直接从业务序列图映射即可得到系统执行者。
理解要点：
一、系统外：系统执行者不是所研究系统的一部分，而是该系统边界外的一个系统。这里的边界指的是责任的边界而非物理的边界。
二、交互：系统执行者必须和系统有交互，不和系统交互的不算是系统的执行者。系统执行者和重要无关，系统执行者只关注谁和这个系统接口，而正真和重要相关的概念是涉众。用例必须在它的路径、步骤、补充约束中考虑这些涉众的利益。
三、功能性交互：执行者和系统发生的交互是系统的功能需求。
四、系统：系统可以是人肉系统，也可以使一个智能系统，甚至是一个特别的外系统——时间。
业务建模映射出系统执行者的方法：与系统交互（存在实的消息线）的人肉系统或其他系统即为系统的执行者。
注意事项：实际工作中，系统执行者和系统用例是一起识别的。
一、不要把执行者和权限管理混淆。用例的主执行者只是表明这个用例是为这一类执行者而做，但不代表系统一定要有权限控制以防止其他的人或电脑系统使用该用例。
b. 系统用例：系统用例的定义是系统能够为执行者提供的，涉众可以接受的价值。
用例识别要点：做需求的目的不是为了安慰自己或者走过场，而是让产品更加好卖，不以这个为出发点的需求工作是没有意义的。即使再难，也只能从涉众的视角来定义需求，切不可贪图方便选一个自己熟悉的视角了事。
一、系统用例可以看做系统执行者和系统之间买卖的平衡点，期望和承诺的平衡点。系统用例可以把需求提升到思考系统“卖什么”的高度。（搞清自己的“用例”，认清自己的定位。）
二、思考用例的过程就是发现价值的过程。
三、“粒度”的问题。开发人员切勿玩弄“粒度原则”、“分层技巧”，应该把屁股挪到涉众那边去，揣摩涉众的心理，实事求是的写下来。
对于判断“用例是否用对”的标准：是否加强了和涉众的联系，如果不是，那就用错了。
业务建模映射出系统用例的识别方法：在业务序列图中，从外部指向所研究系统的消息可以映射为该系统的用例。
识别系统用例的注意事项：
一、主执行者和辅执行者：主执行者从执行者指向用例，而辅执行者从用例指向执行者，主执行者发起用例的交互，辅执行者在交互过程中被动参与进来。场景：主执行者要执行用例，需要辅执行者的帮忙。
二、切勿把到辅执行者的箭头误解为数据传送的方向。
三、主辅执行者是针对某个用例来说的，一个系统在这个用例中充当主执行者，也可以在另一个用例中充当辅执行者。一般说来，辅执行者是人肉系统的情况比较少，更多时候是另一个非人智能系统。
四、用例是涉众愿意“购买”的、对系统的一种“用法”，只要涉众愿意“购买”，当然是越多越好。
五、需求是不考虑“复用“的，如果在考虑”复用“，要紧惕自己是不是已经转换到了设计视角来思考问题。
六、针对不同执行者、不同业务流程，系统提供的价值可大可小，无论大小均是用例。
七、用例的命名。用例命名采用"动宾结构"，宾语前可以加定语，把一句话的主语砍掉，剩下的可以做用例的名字。
常见错误：踏实研究业务流程，做好业务建模，尽量从业务序列图中映射出系统用例，这样的系统用例是不会骗人的。
一、把步骤当作用例。Include（包含）关系的目的是为了复用在多个用例中重复出现的步骤集合，形状往往是多个大用例Include一个小用例。
二、CRUD问题。把数据库的各个表名加上新增、检索、修改、删除就得到了用例的名字或者把四种操作合并称为“XX管理”。
三、玩弄“复用”：用例的执行者不同，背后的涉众利益也有差别，不能简单的合并复用为某一个操作。
四、多个主执行者指向同一个用例。如果用例图已完成，对于这种错误的修改，可以通过泛化出抽象的执行者或者分成几个不同的用例的方法来修改。后一种更常见。
五、玩弄”层次“。切勿偷换"研究对象"，也切勿”把愿景当系统功能“。
六、玩弄”子系统“：用例很多时可以将用例分包，但用例包是在系统的外部对系统功能所做的划分，而子系统则是根据内部部件的耦合和内聚切割得到。
七：模糊的价值：系统往往无法承诺执行者预期的价值时，则该价值不是执行者的用例。主执行者执行用例时，若是需要辅执行者提供实时的帮助后才能进行，则用例正确，否则用例错误。
关于“XX管理”的用例：这种用例无法从业务流程中映射，但系统需要它们来支撑。也只有对于这种支撑的管理基本数据的用例，才用“XX管理”来打扫战场。"XX管理"这样的用例往往是给管理员管理基本数据用的，而且都是千篇一律。
软件工程的“底层”：怎样才能使这段代码更容易维护和扩展？这段代码达到的功能和性能对涉众意味着什么？
2). 系统用例规约：也就是以用例方式组织的需求规约，我们需要通过书写用例规约把用例背后封装的各种相关需求表达出来，并用类图展示用例的各项内容。
用例包含的内容：
a. 前置条件和后置条件：用例通过前置条件、后置条件以契约的形式表达需求。可以想象成：在满足前置条件的开始，按照说明的路径步骤走，就能达到后置条件。
后置条件分类：最小后置和成功后置。最小后置指在用例失败的情况下也要满足的约束，而成功后置指用例成功时系统需要满足的约束。
前置、后置条件的要求：
一、前置条件、后置条件必须是系统能检测的。
二、前置条件必须是用例开始前系统能检测的。
三、前置后置条件是约束，不是动作。
四、前置后置条件要有系统的味道。
五、登录的问题：登录不是用例，不能从登录扩展出产看订单等功能，扩展的正真意思是分支。正确的做法应该是把登录变成被其他用例包含的被包含用例，在写用例规约的时候发现下单、查单等用例都有登录步骤，为节省工作量把这些形成一个小目标的步骤集合分离出一个只能被其他用例包含的用例。如：会员【登录】中，加括号的登录表示这是一个被包含用例，他的步骤和约束在另外的地方描述。
涉众利益的要求：前置条件是起点，后置条件是终点，这中间的最要的内容就是涉众利益，即：某类人担心什么、希望什么，若没有涉众利益很难得到正确的需求。认识到需求由涉众利益的平衡和冲突决定，可以帮助我们直入需求的核心。
一、如何寻找涉众：定位用例涉众的场景：如果系统的这个用例做不好，谁或者哪个系统会遭殃？谁会担心自己的直接利益受侵害？
从执行者触发寻找涉众：若果执行者是人，其便为用例涉众。否则，执行者没有利益主张，不算涉众，但是要留意其背后可能的涉众。
从“上游”寻找涉众：执行者使用系统做某个用例，需要一些资源，这些资源的提供者可能是涉众。
从“下游”寻找涉众：执行者使用系统做某个用例，会产生后果，这个后果所影响到的人也是涉众。
从“信息的主人”寻找涉众：用例用到的相关信息所涉及的某些人（也可能其不知道这个系统的存在）的利益受系统好坏的影响。随着策略环境变化、组织需要调整，原有良好的系统确实要改变，这才是真的需求变更。
从“给涉众排位”寻找主要涉众：涉众排位是否准确，直接影响了需求的内容，开发人员别只盯住了“用户”而忽略了前排涉众。并没有一定的排位准则，只能根据所改进组织的特点归纳总结。
“亲兄弟，明算账”：在描述涉众利益时，要把不同涉众关注的不同利益体现出来。在列出涉众利益后，在照顾前排涉众利益的同时，也要争取兼顾和平衡其他涉众的利益。涉众利益放在用例规约里可以体现出不同涉众针对不同用例有不同利益的特点。
“基本路径”：我们需要写出能够平衡各方涉众利益的路径、步骤和补充约束。用例需要有一条基本路径，若干条扩展路径，首先把基本路径单独分离先写出来，因其代表用例核心价值的路径。
书写路径步骤的要点：
1.) 按照交互四步曲书写：执行者和系统一个个回合进行交互，直到达成目的。每回合步骤分为四类：请求、【验证】、【改变】、回应（有的回合可能没有验证和改变），其中括号表示操作在系统内。
2.) 使用主动语句理清责任：把动作的责任人放在主语的位置，用Cockburn的话就是“球在哪里”。
3.) 主语只能是主执行者或系统。写需求时要把系统当作一个黑箱，仅描述它对外提供的功能和性能，而系统如何构造不属于需求描述的范围。
4.) 使用核心域的概念：路径步骤是功能需求，应该使用核心域的概念来描述，也就是说，要说“人话”。应该避免“技术”、“业务”等名词，而换用“核心域”、“非核心域”来代替。
5.) 不要涉及交互设计的细节：避免把界面细节带入到需求中。“人有眼镜”不是需求，需求是“人能看”。
需求的判断标准：需求是问“不这样行吗”，而不是“这样行吗”。需求确实需要写的细，是需要将需求（问题）写的细，而不是将设计（解决方案）写的细。