在读《软件方法》之前，我对UML的认识还停留在画图表达自己的逻辑与同事交流的阶段。当然《软件方法》也不是一本纯粹的UML书籍，潘加宇用工作流建模方式讲述了实践愿景、业务建模和系统用例在创建系统的使用。作者在这本书中犀利的表达了自己对软件和建模的理解，每个章节都有思维引导和误区提示，给了我很多启发和提示，全书只有241页，生动有趣，图文并茂，阅读起来相对轻松。

潘加宇在传统的软件过程：需求->设计->开发->测试前面增加了业务建模环节。业务建模通过UML的业务用例图和业务序列图，让开发人员抛弃技术思维，审视付钱的组织需要什么样的系统，我开发的系统应该摆放的位置。技术的思维固然重要，前提是当我们在实现系统的时候；用技术思维去分析系统需求会做出一个正确而无用的系统，这样的系统会让销售无奈。所以业务建模的目的就是分析组织，找到组织需要改进的业务逻辑，找到自己系统的定位，让系统有价值起来。

思维导图

结合思维导图，表达一些对作者观点的理解：

核心工作流：业务建模、需求、分析和设计。

思考边界：每个工作流都有自己的核心内容，而工作流之间又有很多相似内容，区分出思考边界，关注工作流的核心内容。整本书中都在帮助读者确认和明确工作流的思考边界，帮助读者建立更明确的模型。

愿景定义和业务建模是对愿意购买软件的组织的研究，这个组织可以是一个单位，也可能是一群志趣相投的人。愿景定义为组织勾勒一份蓝图，业务建模通过对组织业务流程的表达和分析推导出系统。这样的系统是一个有价值的系统，因为它的价值体现在它参与了组织业务流程。它替代组织内一部分人的工作，而且系统可以快速而准确的做完这份工作并且任劳任怨。

在得到一个有价值的系统之后，系统用例和用例规约的目的为系统生成有价值的需求，把系统看做黑盒子，用例执行者（Actor）是系统与外界交互的输入和输出，这样系统为Actor提供的价值就是系统用例。用例规约是对用例的细致描述，通过涉众排位，可以确认出需求优先级的高低。

涉众（stakeholder）也是作者多次提到的概念。作者把传统的用户拆分成了“用例执行者”和“涉众”两部分，这个让我认识业务建模的思路开阔了很多。例如把研究铁路售票处这个组织，如果先入为主的认为售票员是用户，把售票员作为一个重点研究对象的话，会严重束缚系统的业务建模。铁路售票处有多个涉众：旅客，铁路总公司以及政府（中国特色）。旅客关心能不能别让我排一天队买票，能不能买到票；铁总和政府希望旅客能有秩序的买票，不要闹事，不要被电视台曝光等等；虽然涉众不直接操作系统，但是在在组织中的地位明显高于售票员。于是乎12306出现了，网上售票售票员在这个系统中已经消失了，去找售票员问需求是不是走错了路！

阿布思考法分为两步骤：

1、假设有充足的资源去解决问题，得到一个完美的方案；

2、用手上现有的资源区山寨这个完美的方案；

这种隐喻方式把系统改进方法描述的淋漓尽致，让开发者充分发挥想象力，制定一个完美的目标，当然完美的目标结合现实创造出的产品已经足以惊艳全世界了。乔布斯和他的苹果就是这样征服世界的。

这不仅仅是一本技术书架，书中穿插讲述的思维方式会让开发人员受益匪浅，期待作者的后续作品。

---