【读书笔记】--- 拜读潘加宇的《软件方法》一书的摘抄（上）

电子版下载地址：http://www.umlchina.com/book/softmeth.htm   只有前8章，还没有搜索到该书的相关购买信息，等待第8章之后的内容。

 

================以下是摘抄=========================

前置问题： 利润 = 需求 - 设计。
    需求：从卖的视角、具体的实际问题来考虑，将产品当做项目来做一步一步来走。
    设计：从做的角度、抽象的问题模型来考虑，将项目当做产品来做尽力做出彩。
    综述：设计源于需求而又高于需求。
   
    需求规约（如何考虑）：
    组织要解决什么问题                                     => 业务建模
    为了解决组织的问题，待开发的系统应该提供什么功能和性能 => 需求        以上2部分考虑如何提升销售的问题
    为了提供功能，系统内部应该有什么核心机制               => 分析
    为了提供性能，系统的核心机制如何用选定的技术实现       => 设计        以上2部门考虑如何降低成本的问题

    组织          <==>             组织               组织及组织之间是业务建模考虑点
    系统          <==>             系统               系统外部和系统之间是需求考虑点
      =>      系统的核心域          <=                系统内部的核心域是分析考虑点
      <=     系统内部&核心域外部    =>                系统核心域基础上的表示、存储、协议、消息等是设计考虑点

 

0-愿景：确定一个从系统角度出发的非功能描述的范围合理的具体的目标。
    关键点：系统角度、非功能性描述、范围切记太大、一定要具体的目标不要说宽泛的废话。
    愿景格式如下：
        系统：xxxx系统（从系统角度出发，别放大到整个组织）
 老大：xx部门总监（老大指会花钱买这个系统的人，或对购买起着关键作用的决定人）
 目标（度量指标）：（勿拿组织目标当系统目标太宽泛）
 提高xxx人员的工作效率
 减少xxx人员的错误率
 提高xxx工作的准确性

 

1-组织建模(业务建模): 记住你开发的系统只是要替换掉组织中的人工成本，所以建模的对象是组织而不是系统。
    关键步骤：
    1.确定建模组织：（组织的选取需要站在主要利益方和渉利群众的角度考虑，勿草率选取公司这种大范围的组织。对于互联网项目，应该选取项目的目标人群做组织。）画一个圈，把大多数责任可能被（部分/全部）替换的系统（人肉系统/电脑系统...）包在里边。
   
    2.画出组织（业务）用例图和序列图：（从外部看，可以用业务用例图表示组织。从内部看，可以用业务序列图表示组织。）
      研究组织的目的：把系统的价值和组织的价值挂上钩，给组织一个购买系统的理由。
   
 1). 业务用例图：
     a.确定业务执行者：寻找组织的执行者（业务执行者），在组织之外和组织交互的人。（业务执行者是一个组织或人群，而非系统。）
       思考方式：摄像机对准组织边界，谁找组织办事、谁发邮件给组织...等等，谁就有可能是业务执行者。
     b.确定业务工人和业务实体：业务工人是位于组织内部（业务执行者在组织外部）的人肉系统，即组织内的工人，而业务实体就是组织内部的非人工的系统。
       业务工人和业务实体是组织的成本而非价值，所以其不在业务用例图中出现，而是放在“业务对象”的包里。识别业务执行者时不需要画业务工人和业务实体，在画业务序列图时候加上即可。
            c.业务用例和业务流程：把业务流程看作是业务用例的实现，将其组织在业务用例下面。组织里发生的一切都为了给业务执行者提供价值。
       识别业务用例：第一条路线，也是主要路线，方法是从业务执行者开始，思考业务执行和组织打交道的目的。思考的焦点是“执行者对组织的期望和组织对执行者的承诺”的平衡点。第二条路是通过观察组织的内部活动，一直问为什么，向外推到组织外部的某个业务执行者。
       主要执行者和次要执行者：执行者指向用例，这种执行者为主要执行者；用例指向执行者则为次要执行者。如：“出版社→推广书籍→外部译者”可以这样解读：为了给出版社提供推广书籍的服务，组织靠自己的力量不足以完成，需要找外部译者帮忙。
       注意：业务用例是组织为组织服务，在不同的场景中，两个组织的系统形成不同的交互。业务用例是组织的，而不是组织内某个系统的用例。
       

 2). 业务序列图：业务流程有三种描述方式：文本方式、业务活动图方式、业务序列图方式。文本方式生动感欠佳不推荐，业务活动图是主流方式，但推荐的是业务序列图。UML的交互概述图是采用活动图的形式将各个场景的序列图串起来，相当于结合了活动图和序列图的特点。
 
     使用业务序列图原因：
         一、活动图只关注人，序列图把人当作系统。活动图描述流程时，往往会忽略了非人工系统的责任。
         二、活动图表示动作，序列图强迫思考动作背后的目的。序列图不但表达非人工系统的责任，也揭示出某个岗位对外暴露的责任，序列图可以在业务建模和系统建模的过程中始终贯彻“对象协作以完成用例“的思想。
         三、活动图更“灵活”，序列图更不“灵活”。“很容易画”的活动图容易掩盖开发人员对业务流程认识不足或者业务流程本身存在缺陷的事实。序列图强迫开发人员通过alt、loop等结构化控制片段描述业务流程的方式去思考，通过故事来思考待开发系统的位置。
    
     业务序列图要点：
         一、消息代表责任分配而不是数据流动。在序列图中，焦点是对象之间的责任和写作，数据流是作为消息的输入输出参数存在的。建模人员不但要看到数据的流动，还要找出背后的责任。消息代表对他人提供的服务，如果没有指定目的可以用“处理...”来命名，消息名称中不需要带“请求”二字，箭头已表明请求的意义。
  二、聚焦于系统之间的协作。业务建模研究的焦点是组织，所以业务序列图上对象的最小单位是人肉或非人肉系统。建模的基本原则是抽象级别的一致，勿需细化到每一步操作。
  三、只画核心域相关的系统。一个智能系统要不要成为序列图上出现的业务实体，要根据“它是否核心域内的系统”来判断。
  四、把时间看作特殊的业务实体。这样便可以映射到系统用例的时间执行者。注意，时间是外系统，世上只有一个时间系统，定时器是其他系统用来和时间大交道的边界类，定时器会有无数个。
    
     a.绘制现状业务序列图：现状好比拿着摄像机去拍摄，会拍到什么？把拍到的场景如实绘制成业务序列图。根据不同的业务用例，会有多个业务序列图。
         应避免的错误：
      一、把“现状”误解为“纯手工”。业务流程中有人工系统也有非人工的系统，新系统的需求需要通过研究业务现状，再结合愿景推导得出。
      二、以待开发系统为中心拼凑流程。业务建模时，摄像机应该一路跟随着实现业务用例的流程去拍摄，如实反映拍摄的故事，各个系统知识流程中的一个零件。业务建模就是要从业务流程中待到代开发系统的位置，证明该系统对实现业务用例是有帮助的。
    
     b.绘制业务交互概述图：将各个业务用例的序列图串联起来。
     c.改进业务序列图：挑选一个最值得改进的业务序列，阐明原因，然后空降一个系统，画出改进后的序列图，从而得到第一批用例。注意UML建模不是为了“先建模后需求在分析”的顺序而使用，而是迅速定位最值得改进点，得到最有价值的用例，先开发。这才是敏捷。
         改进途径：
  一、物流变信息流。为降低流转成本，尽可能把物流变成信息流，在需要物的时候才将信息变成物。
  二、改善信息流程。可以依靠引入一个新的系统来达到在多个信息系统之间实现信息传递和协调。
  三、封装领域逻辑。通过将人脑中的领域逻辑提炼封装到信息系统中，使人脑得到解放。在绘制业务流程时，非常重要的改进点是：一定要注意画出人脑中的思考逻辑，避免白开水一样的业务流程。前两条改进，系统内部封装逻辑不复杂，效率高，而做到第三条，就可以靠软件的功能就能卖钱。
  四、阿布思考法。
      改进思路是：1.假设有足够的资源去解决问题，得到一个完美的方案；2.用手上现有的资源去山寨这个完美方案。例如：中国组织最得力的会议是靠人脑组织的全国人民代表大会，做会议软件的话可以山寨一二。
      “创新的需求是从观察和思考的汗水中来，不是把拍脑袋闭门造车的所谓‘头脑风暴‘当作调研”。

2-系统建模：与业务建模不同的是研究对象，业务建模的对研究对象是组织，而系统建模的研究对象是系统。
    1.画出系统用例图：有了业务建模的铺垫，系统用例实际上以呼之欲出。
        1). 系统用例图：
     a. 确定系统执行者：系统执行者的定义是在所研究系统外，与该系统发生功能性交互的其他系统。有了前面的业务建模，就不需要头脑风暴了，直接从业务序列图映射即可得到系统执行者。
         理解要点：
  一、系统外：系统执行者不是所研究系统的一部分，而是该系统边界外的一个系统。这里的边界指的是责任的边界而非物理的边界。
  二、交互：系统执行者必须和系统有交互，不和系统交互的不算是系统的执行者。系统执行者和重要无关，系统执行者只关注谁和这个系统接口，而正真和重要相关的概念是涉众。用例必须在它的路径、步骤、补充约束中考虑这些涉众的利益。
  三、功能性交互：执行者和系统发生的交互是系统的功能需求。
  四、系统：系统可以是人肉系统，也可以使一个智能系统，甚至是一个特别的外系统——时间。

  业务建模映射出系统执行者的方法：与系统交互（存在实的消息线）的人肉系统或其他系统即为系统的执行者。

  注意事项：实际工作中，系统执行者和系统用例是一起识别的。
  一、不要把执行者和权限管理混淆。用例的主执行者只是表明这个用例是为这一类执行者而做，但不代表系统一定要有权限控制以防止其他的人或电脑系统使用该用例。

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

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

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