《软件方法 - 业务建模和需求》内容摘要.docx

软件方法是UML China首席专家潘加宇的力作，里面提了很多研发人员常见的知识误区，值得想要在需求分析、系统架构能力有突破的研发人员阅读。此文是本人在拜读此书后的一个知识要点总结，也可以作为大家阅读的参考。（一）软件方法要阐述的核心命题是什么？软件方法主要关注软件研发的四个核心工作流：业务建模、需求、分析、设计，指出“不同工作流产生的工件（Artifact）之间的区别不在于形式，而在于内容，也就是思考的边界”。组织要解决什么问题业务建模提升销售为了解决组织的问题，待开发系统应该提供什么功能和性能需求需求规约为了提供功能，系统内部应该有什么样的核心机制分析降低成本为了提供性能，系统的核心机制如何用选定技术实现设计UML元素可用于各工作流中，推荐用法如下：工作流思考焦点可选UML元素推荐UML元素业务建模组织内系统之间用例图、类图、序列图、活动图用例图、类图、序列图需求系统边界用例图、序列图、状态机图、活动图、文本用例图、文本分析系统内核心域类图、序列图、状态机图、活动图、通信图、包图类图、序列图、状态机图（可选）设计系统内各域之间类图、序列图、状态机图、活动图、通信图、组件图、部署图、时间图、组合结构图、包图不画，代码即设计建模模型的组织方式应按照工作流组织，传统按视图来组织模型的方式容易混淆思考边界。（二）什么是愿景？为什么要明确愿景？怎么明确愿景？什么是愿景：在老大看来，引进这个系统的目的是什么？为什么要明确愿景：缺乏清晰、共享的愿景往往是项目失败的主要原因。怎么明确愿景：（1）寻找老大。要点和典型错误有：要点：老大是买方典型错误：老大就是我们开发公司老总（或者研发总监、产品经理等）要点：系统改善哪个组织的流程？老大就是该组织的负责人。典型错误：老大是xx局信息中心主任李xx。要点：系统好坏的度量指标藏在他的大脑里吗？典型错误：老大是某位大领导（可能是集团董事长，也可能是省长，甚至是总理）做产品而不是项目时，老大就是产品所定位的具体组织和人群。（2）明确可度量的目标。要点有： - 愿景是改善组织的指标，不是做某事； - 不要把系统的功能当作愿景，而应回答这个系统对购买系统的组织有什么好处； - 采用恰当的愿景描述的粒度，不要把组织的目标当作系统的目标； - 必要的时候，需要揣摩“老大”的目标，并对目标排序。（3）关注系统最重要涉众的利益，但不要盲从涉众的利益。（三）业务建模的目的和步骤。业务建模的目的：从组织的角度来定位系统应该提供的价值。缺乏系统的业务建模过程、拍脑袋需求是引起“需求容易变化”的根源之一。核心概念：- 业务执行者：在组织之外和组织交互的人群或组织。- 业务工人：在组织里面，是组织可以替换的零件（可能被新的业务功能或业务实体替换）。- 业务实体：在组织中的非人系统。业务建模的步骤：（1）选定要改进的组织。 - 选定组织的范围要合适。 - 互联网产品要改进的组织，是该网站的目标人群。（2）寻找业务执行者。拿着摄像机对准组织的边界。（3）发现业务用例并建模。 - 业务用例是指业务执行者希望通过和组织交互达到的，而且组织能提供的价值。业务用例代表组织的本质价值，很难变化，改变的是业务用例的实现。从外部看，组织是一些价值的集合，我们可以用业务用例图表示。 - 强调业务用例思考的边界，寻找“执行者对组织的期望和组织对执行者的承诺”。 - 识别业务用例的两条路线：一条是从业务执行者开始，思考业务执行者和组织打交道的目的（主要路线）；另一条是通过观察组织的内部活动，一直问为什么，外推到组织外部的某个业务执行者（补漏路线）。 - 如果一时之间难以确定要改进的业务组织，难以思考组织的用例，可以先不画业务用例图，先画要重点改进的流程的业务序列图，再从中归纳出合适的待研究组织和业务用例。（4）用业务序列图对业务流程现状进行建模。 - 应当避免的错误：把“现状”误解为“纯手工”，应把人和非人系统一致抽象；把“现状”误解为“规范”，规范不一定是真实的；或以待开发系统为中心拼凑流程。 - 使用业务序列图的要点：焦点是对象之间的责任和协作，消息应代表责任分配而不是数据流动；聚焦于系统之间的协作，建模抽象级别应一致；只画核心域相关的系统（核心域的判断依据：是否跟改进的流程无关）；把时间看作特殊的业务实体。（5）改进业务序列图。 - 常见方法：物流变成信息流；改善信息流转；封装领域逻辑；阿布思考法（假设有充足的资源去解决问题，得到一个完美的方案；用手上现有的资源去山寨这个完美方案）。 - “进一步信息化”，不一定需要引进一个全新的系统，也可以通过修改现有系统的责任达到。（四）需求建模。研究对象从研究组织，转变为研究系统。把聚光灯从组织转到要研究的系统，有了业务建模的铺垫，系统的用例图呼之欲出。核心概念：- 系统执行者：在所研究系统外，与该系统发生功能性交互的其他系统（包括人和非人，时间是一个特别的外系统）。- 主执行者和辅执行者：主执行者主动发起用例的交互，辅执行者在交互的过程中被动参与进来，但是两者都是达到用例的目标所需要的。在图示方法上，箭头从主执行者指向用例，从用例指向辅执行者。需求建模的步骤：（1）识别系统执行者。可以从业务序列图映射。 - 在给执行者命名时，尽量不要使用“用户”这种泛词，而是使用具体的执行者名称；做需求时，不考虑复用。（2）识别系统用例。 - 系统用例的定义：系统能够为执行者提供的，涉众可以接受的价值。 - 用例把需求提升到系统“卖什么”的高度，思考用例的过程是发现价值的过程。系统用例可以看作执行者和系统之间买卖的平衡点，期望和承诺的平衡点（例子：“登录”不是取款机的用例）。 - 两个热烈讨论的问题：用例的“粒度”问题（不要把步骤当作用例。用例只能根据涉众心中对系统的期望，最后确定系统能提供什么，不能提供什么）；CRUD问题（“对好卖有帮助”是判断所做的需求工作是否有意义的标准）。 - 用例的常见错误：玩弄“复用”，没有意识到背后的涉众利益有所差别（判断依据：多个主执行者指向同一个用例）；玩弄“层次”，错误的把高层用例和底层用例混在一起，如把业务用例和系统用例混在一起；玩弄“子系统”，错误的把用例分到许多子系统，而正确的用例包应是从外部对系统功能所作的分包；模糊的价值，错误的没有区分系统的价值和组织的价值。 - 用例的几点提示：大用例无妨小用例，针对不同执行者不同业务流程，系统提供的价值可大可小，大的是用例，小的也是用例，只要是从涉众的视角得到；用例的命名，不要使用弱动词。（3）书写系统用例规约： - 前置条件与后置条件：必须是系统能检测的；是约束，不是动作；要有系统的味道，杜绝正确而无用的废话；被包含用例（以及扩展用例）严格来说不能算用例，应该有更好的名字。 - 涉众利益 - 基本路径：按照交互四部曲（请求、验证、改变、回应）书写；使用主动语句理清责任，把动作的责任人放在主语的位置；主语只能是主执行者或系统，把