然后映射到软件方法的话（我不知道，软件方法具体应该怎么划分，百度搜了下，说有8种方法来着，很多都没见过了）面向对象，就对应了：面向对象分析设计，比较流行的工具是UML看面向对象的历史，60-70年代好像就提出了编程范式，90年代分析设计思想好像就成熟了我有个问题，90年代到现在，30年过去了，技术改变了很多，进化了很多代（编程语言、平台、框架等等，一直在变化）难道软件方法这30年没有进步吗？我们是不是还停留在90年代？前面的业务建模、需求、分析进步不大，当然也是有的，例如《软件方法》就是进步嘛。但从大众普及面上来说，是倒退的（如果说方法水平是铁器时代，大众平均估计是石器时代甚至还要落后）。原因刚发布的第8章里面有描述。按照一致的标准来看，编程语言也没啥进步，函数式编程语言60年代就有了，现在面向对象语言的很多所谓“更新”，就是把函数式编程混杂进来。编程语言能力，从普及层面上也是倒退的。二十多年前我去应聘程序员，人家让我做“餐馆安排座位”的题目，现在招程序员，考“哪个是Thread类的方法”。也就是说，人现在根本还没有充分掌握并利用现在技术来解决问题，还没达到抱怨技术进步慢的地步。一个破伤风都不知道怎么应对，动不动就死翘翘的水平，就先不要抱怨“怎么还没攻克癌症”。业务建模→需求→分析→设计，新技术要能够封装某个环节中间的推导智慧，才能取得大的进步，否则在小的环节上折腾已经很难。比较容易的是分析→设计的推导，这个映射比较有规律。想办法提高人脑需要编辑的“源代码”的抽象级别，只需建模清楚领域逻辑，就能映射为最终可运行的实现，这个目前某些工具在某些平台是可以做到的，例如Rhapsody在嵌入式开发中。我们在下册中提到的工具，是希望封装业务建模→需求的智慧。（本文无图片，尝试在封面放一张B站截图看能否多一些点击）[2020.01加一套题]UMLChina建模竞赛题大全-题目全文+分卷自测（11套110题）