《软件方法》这本书通过对软件开发过程中常见问题和解决方法的介绍，帮助读者更好地理解和应用软件开发的方法论。作者通过实际案例和经验分享，深入浅出地阐述了软件方法的重要性和实用性，为软件开发者提供了宝贵的指导和启发。阅读后让人受益匪浅。
软件方法读后感(一)
于 p.205 潘老师说：“设计约束既不是功能需求，也不是非功能需求...设计约束是需求的一种，也一样要从涉众的视角描述。”我凌乱了，这么简单的二元逻辑（功能与非功能）也被扯成这样，新的第三种需求类型因为潘老师而诞生，真可谓中国UML江湖的又一大创举啊！我猜这与潘老师是搞化学的出身，大概没学过离散数学集合论有关吧。正确的说法是：既然设计约束不是功能需求，那么它必然也是一种非功能需求。
软件方法读后感(二)
患者确实是医院的执行者 p.60
储户来存钱，企业来贷款，人民银行要对它作监管，这些就是该商业银行的执行者 p.54
...
请问这些是中国人的语文吗？
如此荒唐造句的原因在于作者固执地一定要把 Actor 译作“执行者”。而 UML 中的 Actor 其实代表了业务/系统的直接用户、外部参与者在参与 Use Case 活动中所承担的一种角色，根本不是系统的执行者！
请分清系统的客户、请求者、被服务对象，与执行者、被请求者、服务者的方向好么？
软件方法读后感(三)
也许是因为我已经有多年的经验，我认为此书超过我过去看过的任何一本讲具体软件过程方法的书。
无论如何，我认为做过二、三年软件开发的程序员，应该人手一册此书。更不用说，从事产品设计、业务/需求分析，软件项目经理，将软件“愿景”落实到可编码开发阶段的人。
特别推荐，如果你专门从事项目研发、信息化建设，此书你应该好好看上三五遍。
从来没有像这样推荐过一本书，作者以精湛的“建模”技术、方法、经验，向我们展示了软件开发活动中的重要、核心环节，以系统、独特、有趣、还能跟“互联网”结合的视角将这些环节一一解剖。我认为这本书就是“正统”的武功，像“降龙十八掌”，“九阳神功”之类。
作者以多年的培训指导经验出发，除了文字以外，在每一章、节之处，都附有有趣的“思考题”，让读者加深印象，锻炼思考，实是作者用心良苦啊。
话说，我跟作者没有半毛关系，我是偶然在寻找UML建模工具时，在UMLCHINA上看到的此书推荐，我想，既是UMLCHINA推荐，买来看看吧，曾经我也是UMLCHINA的“匿名用户”，支持一下他们老大吧。想不到，买了之后如此喜欢。
我还没看完，看完也许还有补充。
软件方法读后感(四)
1、从实用主义角度来看这本书
虽然这本书，以及潘老师一直在强调，建模能力就是公司竞争力，而绝大多数公司不具有这个能力，但是他并没有举出例子，哪些具有建模能力的公司发展的特别牛逼
所以还是辩证看待
2、目前从这本书吸取到的
2.1 好好画图：按照 uml 规范去画，理解 uml 背后的含义，一招一式
2.2 利润 = 需求（收入） - 设计（成本）
- 需求是为了让软件更好卖、赚更多钱
- 设计是为了减少研发、运营、维护等成本
3、作者的叙述方式比较啰嗦和口水，需要有一些耐心
对作者感兴趣的可以搜下作者的课程视频，表达方式确实比较独特，不是一般人可以耐心接受的，所以还是那句话，辩证吸收，吸取那些你认可的，不认可的就扔一边就好。
软件方法读后感(五)
读完潘老师的这本大作，我的总体印象是：
概念不清，用词不当，东拉西扯，逻辑错乱。
全书中那些令人啼笑皆非的荒唐错误结论和缺陷主要有：
- 设计约束是需求，但既不是功能需求，也不是非功能需求（潘老师不懂最简单的二元逻辑？）；
- 全书对于“涉众”（Stakeholder）这个基本术语的理解几乎通篇是错误的，而且前后矛盾；
- UML 模型不是用来和涉众沟通的！（很难相信这是一位 UML 首席专家的言论）；
- 涉众没有资格、也没有责任提供需求；
- 把 Actor 译成“执行者”，导致许多违反中文常识的语病，如：人民银行是商业银行的执行者，患者是医院的执行者；
- 系统 Actor 和重要无关，和重要有关的概念是涉众；
- 观众（涉众）在台下看，Actor 在台上表演（其实呢，台上的演员也是涉众）；
- 需求或用例的“粒度”、“层次”这些概念其实并不存在，对开发人员的误导相当严重；
- 设计就是代码，所以设计工作流不推荐画 UML 图；
- 界面组件不是需求。人有眼睛不是需求；
- 只用两三章介绍了 UML 的用例图和业务序列图，未强调业务活动图，也未详细介绍 UML 需求分析中常用到的其他图形，如系统序列图、活动图、状态图等（内容单薄、片面）；
- 第 2 章所谓的“愿景”，只是区区几个“老大”或涉众的目标，名曰“度量指标”，却连一个数量也没有说明，实质内容与愿景文档差距甚远；
- 作为需求分析的名著，从第 3 章到第 6 章的重点章节只介绍了以用例为主的动态建模，未详细介绍需求分析的另一半——静态建模（如领域建模、概念建模）；
...
基于以上这些错误和缺陷，我给全书的评价是将将及格，只达到了业余研究 UML、需求分析的中等水平，潘老师作为 UML 中国业余的首席专家名至实归，恭喜恭喜！
UMLGreatChina 首席专家、创始人 张恂 ;-)
软件方法读后感(六)
《软件方法上-业务建模和需求》
如何做好一个软件？
一个软件要做的工作可以量化么？如果能量化，那有流程么？如果有流程，那有方法么？
大学学的是计算机，但是最不愿从事的行业就是软件。结果呢，出了校门现在，一干就是8年。我并不是在摆什么资质，因为我们应该清楚，一份工作你重复干了8年，你的经验并不是8年，而是一年而已。
《软件方法》讲的是用UML语言来辅助我们进行软件的从0到1的过程。这个过程的结果并不是最终运行在电脑屏幕上的那个界面，而是一堆图纸，可视化的图纸。
是的，确实是图纸。建筑行业有设计和施工图纸，电工行业有设计和实施图纸，城市规划有图纸··· ···任何你看得到的工程都有图纸，你要写的软件居然没有。
“图纸在我脑子里呢”，我也曾经说过。直到看到这本书。
这本书的直接受众应该有两类人：
1.程序员
这类人一般的工作思路就是提功能的人说要做什么，嗯嗯哦哦之后，迫不及待的打开编辑器开始写代码，调试，然后发现做完的东西，总是被告知要修改，没玩没了的改。
2.项目管理者
这类我们称之为“IT包工头”，他们既要跟客户聊需求，转头还要跟程序员转述。作为一个中间人，两边都要沟通，现实是两边都没沟通好。用户说的不就是这样的么？怎么做出来的东西就是不对呢！面对需求和变更，他们是最无奈的，因为他们面对的并不只是程序，而是公司的成本和效益。
我甚至推荐产品经理也来看看这本书，因为一个产品到底要满足谁的需求，提供什么样的功能是一开始就要想清楚的事情。精益思想的逐步迭代改进是没错，但是也要求你在产品之初，能想明白你产品到底能带来什么样实实在在的客户价值。
很庆幸能在工作的第8个年能看到这本书，更荣幸的是，和自己的团队在一起用了7个课时一起讨论学习，一起做作业。最让人兴奋的，是每一次在进行项目讨论的时候，我们都开始用《软件方法》中学到的知识，用新的方法在做我们每天都该去的的事情：内部沟通更加有条理了；需求变更更加谨慎了，和客户的沟通更加有效率了··· ···
这是不只是一本书的作用，更是不断打破自己习以为常的工作方式的决心。
希望大家一起加油！
软件方法读后感(七)
这是我在CSDN上发的一篇关于此书的评论。大家可以看看，谢谢！
作为一个野路子过来的程序员（呵呵，一直自我标榜是程序员，为这个名字骄傲！），一直是自己学习，一直是自己摸索做软件。每次拿到一个所谓的“项目”吧，都是根据用户的需求，做点改动，改点做点。做了一些吧，感觉一方面开发工具使用来使用去，都是那些，开发包嘛都是别人的，拿过来研究研究API，先实现功能再说吧。时间长了，总觉得缺点什么东西，缺点什么东西呢？用户老是抱怨软件不是他要的，我也老是觉得用户在故意找问题；源代码乱七八糟，网上这找一段，那抄一段，东西倒是做出来了，但却没有什么积累；开发过程也很让人熬心，今天一个功能，明天一个功能，尽管功能不同，但好像很多是重复的，感觉只是在做无意义的机械拼凑；东西倒是好不容易做出来了，过一段时间，有类似的开发了，好像也找不到能够从以前的开发中能直接拿出来有用的东西。我觉得我应该去寻找软件开发本质的东西了。
问了很多人，人家说，软件工程和架构设计可能是你需要的答案，去寻找吧！那时，网上最多的是UML的介绍，于是，我感觉找到了目标一样，疯狂地找啊！那时基础也不好，就从最初的看起，电子书、视频资料找了不少，实物书也买了些看，知道了一些基本概念，学会了某些软件的一些基本操作，可是感觉还是不得劲，用不到开发中去。我似乎觉得可以在开发能够坚持的东西，我没有学到。直到我去年在偶然间从网上下载了潘加宇老师的这本《软件方法上册——业务建模和需求》，我读完第1章，就感觉这本书就是我想要的东西！对于我这种野路子程序员，想要在软件工程和架构设计方面提升自己，太需要一招一式地练好基本功了，而这本书，就是拳谱！如果说那些大师级的著作是《九阳神功》的话，那这本书，我觉得就是《武当长拳》了，练好它，从程序员升级到架构师才有基础。
尽管这本书，作者目前只出了上册，但还是想写写读后感！
第1章，是这本书的总纲（哈哈，让我想起了《七伤拳》的总纲），一下就点出了软件开发的三个本质。第一是用“利润=需求-设计”这一公式指出了软件开发中需求和设计这两个活动对商业利润的直接影响，并让这两个活动在软件开发当中泾渭分明；这让我认识到，软件工程的目标就是使从需求到设计的转化过程，更加明朗化、规范化；明朗化是使人清楚地知道做哪些事，规范化是如何标准地做这些事。第二是点出了软件过程的核心工作流及其思考边界；核心工作流倒还好说，但凡接触过一点软件开发都能说出个一二三，只是每个工作流的本质区别是什么，估计都不甚了了了，反正我是一个野路子程序员，对此更是不明白了，我读到此处时，收获就很大，一下子脑子就清晰了，原来每个核心工作流的本质区别就是其思考边界，或者说思考问题的目标不一样了；这就好像练武功的每一招所练的肌肉、或者穴位，都不一样。第三是在核心工作流中有效利用UML工具，并实现开发团队内部顺畅交流的问题；UML为我们提供了软件开发的利器，这就像武器架上排好了刀、枪、剑、戟、斧、钺、钩、叉，现在该你上场了，你该使用什么趁手的兵器（呵呵，千万不能像孙猴子那样说都不趁手哦！）？这个部分的讲解，就是一个师傅坐你旁边了，你新手上路，心里踏实呀！本章的最后，点出了软件开发团队实施过程容易陷入形式化的根源，就在于技能不足，所以，练好这一招一式吧！
第2章，通过愿景的描述，理清了系统开发相关各方，在开发过程中的关系。愿景，系统开发的总目标、大方向，抓住它很重要呀！但更重要的是作者透过愿景，说明了系统开发各方的关系。以前我理解Actor，就是执行者，翻译的呗，按对作者说法的理解，这个翻译有点偏了，Actor是台上的演员才更准确；Stakeholder是涉众，我以前理解与系统相关就是涉众呗，作者说，理解为台下拿票（利益）的holder才更合理呀！于是，脑中的画面感出来了，一群Stakeholder按重要性由前排后，看台上Actor操作着系统的一个个用例。一下子，各方关系就清晰了。本章最后，点明了涉众利益是稳定的东西，是可以积累的财富，这为后面我们如何抓住软件开发中，本质的东西奠定了基础。
第3、4章，表面上在讲如何研究业务，但实际上是在讲待开发系统与组织的关系。注意，这个时候，思考问题的边界是在组织与组织之间。第3章开头就指出软件只是组织的零件，这实质上是讲软件的定位问题，以前总觉得自己做的系统多牛、多好、多重要，但看到此处，原来自己的“宝贝”只是组织为了改进业务而加入的一个零件而已，呵呵，不要太自以为是了。然后，通过认识组织对外体现出的价值，识别出业务用例，最开始，我也读到此处也有些混了，业务用例好像是个新词，和开发系统时讲的用例有什么一样？一样之处，就是这个“价值”。第4章，开始认识要体现组织的价值，组织内部要做些什么事了，这就通过业务序列图来体现，认真研究业务序列图，从物流变信息流、信息流转改善、领域逻辑封装三个方面来改进业务，得到改进后的业务序列图，注意，得到了这个图，我们要开发的系统的定位、职责，就基本可以确定了。
第5-7章，是介绍使用用例技术来认识需求。此时，思考问题的边界转到组织内部的系统与系统之间了。系统用例的认识过程也是通过“价值”来体现的，这和前面类似。第6章，我觉得讲解得十分精彩，具体讲解到了用例规约技术中各个部分的意义和作用，这一点是我在其它书里面没有看到的，这让我在以后写用例规约时，觉得更有指导了。最后第7章，讲了些进行需求获取的方法。
整体上，全书语言平实易懂，概念总是在缓如细流的讲解中，自然地流出，这也是得益于本书是出自作者进行培训的讲稿；另外，本书有许多地方也值得在项目使用当中慢慢体会，反复咀嚼；难能可贵的是，作者为读者的实践想得到位，提供了核心工作流的模型模板，并在讲解中穿插EA的使用方法，为新手打开了方便之门！本书也指出了很多错误的认识，并举例进行了纠正。另外，在许多书中模棱两可的经验性方法的介绍，比如用例的得出，在本书中则是通过逻辑的推理，自然而然地得到了发掘，更符合我们搞理工科的人的思维方式。总之，全书的讲解，我觉得都像是师傅在一招一式地指点我，一点一滴地纠正我，期望我能顺利地使用到后面的开发中，并在坚持使用中不断进步。
最后，期望作者能笔耕不辍，本书的下册能够赶紧出版，满足我这种饥渴的读者。
软件方法读后感(八)
在面向对象的需求分析方法中，UML的地位是不容动摇的。
在和很多做产品做需求的小伙伴聊过后发现大家对UML的了解非常的少，在之前组织的需求分析实战中也发现了这一点。
反而对程序员GG来说，UML的普及率会更高一些。
有的人会说，我不用UML，需求分析的也挺好的啊，产品做的也没什么问题啊。
如果你正面临着下面这些问题，我建议你看一下这篇文，并且学习并应用UML。
- 我对自己的产品功能了如指掌，但是却无法总结出所有的系统角色特征
- 测试写的用例我提不出意见，但是测试结束后我却经常发现之前没有想到过的用例
- 在做原型及需求文档时，有时候会遗漏某个功能或者场景
- 与程序猿经常无法沟通，我觉得自己写的文档、画的原型已经很清晰了，但是他们就是看不懂
- 我完全不知道产品中的业务主流程在执行的过程中会有哪些对象参与
什么是UML？
统一建模语言（UML，UnifiedModelingLanguage）是面向对象软件的标准化建模语言。UML因其简单、统一的特点，而且能表达软件设计中的动态和静态信息，目前已成为可视化建模语言的工业标准。在软件无线电系统的开发过程中，统一建模语言可以在整个设计周期中使用，帮助设计者缩短设计时间，减少改进的成本，使软硬件分割最优。
简而言之就是一种语言，一种规范。就好像音乐用五线谱、简谱表达，数学用公式表达，需求模型用UML来表达。曾经有的人希望在需求阶段将UML做的很规范，并可以由此直接生成代码。就像现在的原型可以直接生成页面代码一样。现在已经有很多工具可以做到这些了，虽然生成的代码不是那么的让人满意。但是不排除未来掌握UML和业务的人员直接跳过程序员编写软件产品。
UML带给需求分析什么？
以小婧使用UML的经验来看，UML会给需求分析及需求相关人员提供更清晰、明确的目标。
我经常说，用UML重点是要充分应用它面向对象的分析方法。也就是在做业务分析的时候，将信息抽象成对象进行分析，可以使得自己避开“干扰”信息，抓住“主线”。
你会对你的解决方案更加有信心，知道哪些地方存在改善的空间，会给用户带来什么价值。如果发生需求变更，你也会很清晰的识别出影响点。
你设计出来的产品和业务流程会更加连贯、合理、有逻辑性，模块及功能之间的耦合关联也非常清晰。就好像你看蜘蛛网仿佛毫无章法，但是仔细看来却是一件完美的艺术品。
UML适用于哪些阶段？
而我们从UML的定义也可以看出，UML主要是服务于设计的。在需求分析阶段，我们如果能很好的使用UML，将会为代码设计提供很好的支持。
UMLChina在《软件方法》一书中提出了一个概念叫核心工作流。使用核心工作流可实现“低成本制造好卖的产品”。
1 业务建模——组织要解决什么问题
做产品需求的人都知道，我们需要去找甲方的痛点也就是问题，如果我们的产品可以很好的解决问题，那么人家就愿意付钱，我们就能盈利。
而你的产品能带给用户什么价值，这个价值到底是否足够大到吸引用户来付费。你可以通过业务建模来进行分析。要知道引进一个软件系统，和招聘一名新员工没有本质的区别。我以前经常会被challenge的问题是：我为什么要买你们的系统，我用Excel也管的挺好的。
业务建模阶段思考的焦点是：组织内系统之间
推荐UML元素：用例图、类图、序列图
2需求——为了解决组织的问题，待开发系统应该提供什么功能和性能
这里强迫我们从“卖”的角度思考哪些是干系人在意的，哪些不是。
需求阶段思考的焦点是：系统边界
推荐的UML元素：用例图、文本
3分析——为了提供功能，系统内部应该有什么样的核心机制
在用户的整个业务流程中，你的产品是在哪个部分起什么作用的。大部分的软件产品的作用就是取代人工，实现自动化。以前我们去餐馆点菜需要服务员拿个小单子来写你点了哪些菜，或者直接人脑记忆；付款的时候，老板要收集小单子或者记录在小本子上，以便休息的时候计算营业额。但是现在我们去吃饭，直接一个IPAD，菜单、点菜、消费记录全部自动化。装在IPAD里的系统是通过分析得到的。
在分解阶段思考的焦点是：系统内核心域
推荐的UML元素：类图、序列图、状态机图
4设计——试了提供性能，系统的核心机制如何选定技术实现
主要聚焦：系统内各域之间
UML：不画，代码即设计
从上面几个阶段我们可以看出，对于我们产品需求人员需要掌握的UML其实只有那么几种：用例图、序列图、类图、状态图。
有人会问，为什么没有活动图（流程图）？我觉得如果你和用户或者业务人员沟通，可以使用活动图、但是如果你是为研发、设计服务，建议使用序列图。因为序列图会强迫你去思考所有的动作背后的目的。
【图】
关于各种图的具体画法我觉得大家去问度娘会得到比我这有限篇幅更详细的信息。而针对用例图，我最近看到一种说法，觉得很有意思，在本文中做一个分享。
潘加宇老师在《软件方法》中提到了两种用例图：业务用例图和系统用例图。
之前有小伙伴说，测试和开发看不懂他画的用例图，很苦恼。我仔细看了下，确实是有些表述不清。因为他把业务用例图和系统用例图弄在一起了。
业务用例图
业务用例图主要是用在业务建模的阶段，目的是从甲方的角度来定位系统应该提供的价值。所以业务用例图研究的对象是甲方组织。甲方的组织里面包括哪些角色，哪些软件系统，哪些部门？而我们的系统将承担这些对象中的哪些对象的大部分职责？
另外一方面，业务用例图的Actor执行者是业务执行者，即组织外与组织交互的人群或组织。比如你的甲方是某商业银行，其Actor是储户、企业用户、人民银行。研究的是他们将会与商业银行产品什么用例。
系统用例图
系统用例图主要使用在需求阶段，我们其实最常用的是系统用例图。系统用例图的主要研究对象是系统，也就是我们待开发的软件系统。
系统用例图的执行者是在系统外与系统发生功能性交互的其他系统。所以重点在于这个执行者与系统发生功能性交互。比如前些日子小婧的身份证过期了去办身份证（我又暴露年龄了）。身份证办理系统的执行者包括：办证人员、数码相机、指纹采集仪。这里要注意的是我并不是系统的执行者，至少在这个非自助的系统中，我不是。
---
写在最后
在实际的产品需求分析过程中使用UML，不论对你的产品还是你自己而言都会收益颇多。
但是和所有的方法一样，在学习和实践一种新的方法时会面临很多的挑战，也会有很多的问题。
单纯就从UML的角度来说，我觉得有这样几个方法可以来学习实践：
- 对自己产品进行梳理，尝试用UML的用例图、序列图（时序图）绘制现有系统业务，并与开发人员讨论。通常来说，开发对UML的了解会更深入，这可能是和现在常见的开发语言，比如C系列、Java等也是面向对象的语言有关。
- 度娘UML的绘制方法。现在很多文章和博客都介绍的很详细。
- 通过阅读一些比较经典的UML书籍。
- 欢迎和小婧进行沟通交流。
小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
