一招一式练武功—读《软件方法上册：业务建模和需求》有感
作为一个野路子过来的程序员（呵呵，一直自我标榜是程序员，为这个名字骄傲！），一直是自己学习，一直是自己摸索做软件。每次拿到一个所谓的“项目”吧，都是根据用户的需求，做点改动，改点做点。做了一些吧，感觉一方面开发工具使用来使用去，都是那些，开发包嘛都是别人的，拿过来研究研究API，先实现功能再说吧。
时间长了，总觉得缺点什么东西，缺点什么东西呢？用户老是抱怨软件不是他要的，我也老是觉得用户在故意找问题；源代码乱七八糟，网上这找一段，那抄一段，东西倒是做出来了，但却没有什么积累；开发过程也很让人熬心，今天一个功能，明天一个功能，尽管功能不同，但好像很多是重复的，感觉只是在做无意义的机械拼凑；东西倒是好不容易做出来了，过一段时间，有类似的开发了，好像也找不到能够从以前的开发中能直接拿出来有用的东西。我觉得我应该去寻找软件开发本质的东西了。
问了很多人，人家说，软件工程和架构设计可能是你需要的答案，去寻找吧！那时，网上最多的是UML的介绍，于是，我感觉找到了目标一样，疯狂地找啊！那时基础也不好，就从最初的看起，电子书、视频资料找了不少，实物书也买了些看，知道了一些基本概念，学会了某些软件的一些基本操作，可是感觉还是不得劲，用不到开发中去。我似乎觉得可以在开发能够坚持的东西，我没有学到。
直到我去年在偶然间从网上下载了潘加宇老师的这本《软件方法上册——业务建模和需求》，我读完第1章，就感觉这本书就是我想要的东西！对于我这种野路子程序员，想要在软件工程和架构设计方面提升自己，太需要一招一式地练好基本功了，而这本书，就是拳谱！如果说那些大师级的著作是《九阳神功》的话，那这本书，我觉得就是《武当长拳》了，练好它，从程序员升级到架构师才有基础。
尽管这本书，作者目前只出了上册，但还是想写写读后感！
第1章，是这本书的总纲（哈哈，让我想起了《七伤拳》的总纲），一下就点出了软件开发的三个本质。
第一是用“利润=需求-设计”这一公式指出了软件开发中需求和设计这两个活动对商业利润的直接影响，并让这两个活动在软件开发当中泾渭分明；这让我认识到，软件工程的目标就是使从需求到设计的转化过程，更加明朗化、规范化；明朗化是使人清楚地知道做哪些事，规范化是如何标准地做这些事。
第二是点出了软件过程的核心工作流及其思考边界；核心工作流倒还好说，但凡接触过一点软件开发都能说出个一二三，只是每个工作流的本质区别是什么，估计都不甚了了了，反正我是一个野路子程序员，对此更是不明白了，我读到此处时，收获就很大，一下子脑子就清晰了，原来每个核心工作流的本质区别就是其思考边界，或者说思考问题的目标不一样了；这就好像练武功的每一招所练的肌肉、或者穴位，都不一样。
第三是在核心工作流中有效利用UML工具，并实现开发团队内部顺畅交流的问题；UML为我们提供了软件开发的利器，这就像武器架上排好了刀、枪、剑、戟、斧、钺、钩、叉，现在该你上场了，你该使用什么趁手的兵器（呵呵，千万不能像孙猴子那样说都不趁手哦！）？这个部分的讲解，就是一个师傅坐你旁边了，你新手上路，心里踏实呀！本章的最后，点出了软件开发团队实施过程容易陷入形式化的根源，就在于技能不足，所以，练好这一招一式吧！
第2章，通过愿景的描述，理清了系统开发相关各方，在开发过程中的关系。愿景，系统开发的总目标、大方向，抓住它很重要呀！但更重要的是作者透过愿景，说明了系统开发各方的关系。以前我理解Actor，就是执行者，翻译的呗，按对作者说法的理解，这个翻译有点偏了，Actor是台上的演员才更准确；Stakeholder是涉众，我以前理解与系统相关就是涉众呗，作者说，理解为台下拿票（利益）的holder才更合理呀！
于是，脑中的画面感出来了，一群Stakeholder按重要性由前排后，看台上Actor操作着系统的一个个用例。一下子，各方关系就清晰了。本章最后，点明了涉众利益是稳定的东西，是可以积累的财富，这为后面我们如何抓住软件开发中，本质的东西奠定了基础。
第3、4章，表面上在讲如何研究业务，但实际上是在讲待开发系统与组织的关系。注意，这个时候，思考问题的边界是在组织与组织之间。
第3章开头就指出软件只是组织的零件，这实质上是讲软件的定位问题，以前总觉得自己做的系统多牛、多好、多重要，但看到此处，原来自己的“宝贝”只是组织为了改进业务而加入的一个零件而已，呵呵，不要太自以为是了。然后，通过认识组织对外体现出的价值，识别出业务用例，最开始，我也读到此处也有些混了，业务用例好像是个新词，和开发系统时讲的用例有什么一样？一样之处，就是这个“价值”。
第4章，开始认识要体现组织的价值，组织内部要做些什么事了，这就通过业务序列图来体现，认真研究业务序列图，从物流变信息流、信息流转改善、领域逻辑封装三个方面来改进业务，得到改进后的业务序列图，注意，得到了这个图，我们要开发的系统的定位、职责，就基本可以确定了。
第5-7章，是介绍使用用例技术来认识需求。此时，思考问题的边界转到组织内部的系统与系统之间了。系统用例的认识过程也是通过“价值”来体现的，这和前面类似。第6章，我觉得讲解得十分精彩，具体讲解到了用例规约技术中各个部分的意义和作用，这一点是我在其它书里面没有看到的，这让我在以后写用例规约时，觉得更有指导了。最后第7章，讲了些进行需求获取的方法。
整体上，全书语言平实易懂，概念总是在缓如细流的讲解中，自然地流出，这也是得益于本书是出自作者进行培训的讲稿；另外，本书有许多地方也值得在项目使用当中慢慢体会，反复咀嚼；难能可贵的是，作者为读者的实践想得到位，提供了核心工作流的模型模板，并在讲解中穿插EA的使用方法，为新手打开了方便之门！
本书也指出了很多错误的认识，并举例进行了纠正。另外，在许多书中模棱两可的经验性方法的介绍，比如用例的得出，在本书中则是通过逻辑的推理，自然而然地得到了发掘，更符合我们搞理工科的人的思维方式。
总之，全书的讲解，我觉得都像是师傅在一招一式地指点我，一点一滴地纠正我，期望我能顺利地使用到后面的开发中，并在坚持使用中不断进步。
最后，期望作者能笔耕不辍，本书的下册能够赶紧出版，满足我这种饥渴的读者。
————————————————
版权声明：本文为CSDN博主「陶朱子」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u014418598/article/details/22748941
[推荐升级]23套UML+EA和StarUML的建模示范视频-全程字幕（2022.6.1更新）
《软件方法》书中自测题-题目全文+分卷自测（1-8章）16套111题
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]