08丨软件设计的方法论：软件为什么要建模？

Dec 6, 2019

08丨软件设计的方法论：软件为什么要建模？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

08丨软件设计的方法论：软件为什么要建模？

2019-12-06 李智慧来自北京

《后端技术面试 38 讲》

课程介绍



讲述：李智慧

时长11:28大小10.50M



我们开发的绝大多数软件都是用来解决现实问题的。通过计算机软件，可以用高效、自动化的方式去解决现实中低效的、手工的业务过程。
因此软件开发的本质就是在计算机的虚拟空间中根据现实需求创建一个新世界。阿里的工程师在创造一个“500 平方公里”的交易市场，百度的工程师在创造一个“一万层楼”的图书馆，新浪微博的工程师在创造“两亿份报纸”，腾讯的工程师在创造“数 10 亿个聊天茶室和棋牌室”。
现实世界纷繁复杂，庞大的软件系统也需要很多人合作，开发出众多的模块和代码。如何使软件系统准确反映现实世界的业务逻辑和需求？庞大的软件系统如何能在开发之初就使各个相关方对未来的软件蓝图有清晰的认知和认可，以便在开发过程中使不同工程师们能够有效合作，能够让软件的各个模块边界清晰、易于维护和部署？
这个由软件工程师创造出来的虚拟世界，是一个恢弘大气的罗马都城，还是一片垃圾遍地的棚户区，就看软件工程师如何设计它了，而软件设计的主要过程就是软件建模。
软件建模所谓软件建模，就是为要开发的软件建造模型。模型是对客观存在的抽象，我们常说的数学建模，就是用数学公式作为模型，抽象表达事务的本质规律，比如著名的 E=mc2，就是质量能量转换的物理规律的数学模型。除了数学公式是模型，还有一些东西也是模型，比如地图，就是对地理空间的建模。各种图纸，机械装置的图纸、电子电路的图纸、建筑设计的图纸，也是对物理实体的建模。而软件，也可以通过各种图进行建模。
通过建模，我们可以把握事物的本质规律和主要特征，正确建造模型和使用模型，以防在各种细节中迷失方向。软件系统庞大复杂，通过软件建模，我们可以抽象软件系统的主要特征和组成部分，梳理这些关键组成部分的关系，在软件开发过程中依照模型的约束开发，系统整体的格局和关系就会可控，相关人员从始至终都能清晰了解软件的蓝图和当前的进展，不同的开发工程师会很清晰自己开发的模块和其他同事工作内容的关系与依赖，并按照这些模型开发代码。
在软件开发中，有两个客观存在，一个是我们要解决的领域问题，比如我们要开发一个电子商务网站，那么客观的领域问题就是如何做生意，卖家如何管理商品、管理订单、服务用户，买家如何挑选商品，如何下订单，如何支付等等。对这些客观领域问题的抽象就是各种功能及其关系、各种模型对象及其关系、各种业务处理流程。
另一个客观存在就是最终开发出来的软件系统，这个软件系统也是客观存在的，软件由哪些主要类组成，这些类如何组织构成一个个的组件，这些类和组件之间的依赖关系如何，运行期如何调用，需要部署多少台服务器，服务器之间如何通信等。
所有这两个方面客观存在的抽象，就是我们的软件模型，一方面我们要对领域问题和软件系统进行分析、设计、抽象，另一方面，我们根据抽象出来的模型开发，实现出最终的软件系统。这就是软件开发的主要过程。而对领域问题和软件系统进行分析、设计和抽象的这个过程，我们专门划分出来，就是软件建模与设计。
4+1 视图模型软件建模比较知名的是 4+1 视图模型，准确地说，4+1 模型不是一种软件建模工具和方法，而是一种软件建模方法的方法，即建模方法论。
4+1 视图模型认为，一个完整的软件设计模型，应该包括 5 部分的内容：
逻辑视图：描述软件的功能逻辑，由哪些模块组成，模块中包含哪些类，其依赖关系如何。
开发视图：包括系统架构层面的层次划分，包的管理，依赖的系统与第三方的程序包。开发视图某些方面和逻辑视图有一定重复性，不同视角看到的可能是同一个东西，开发视图中一个程序包，可能正好对应逻辑视图中的一个功能模块。
过程视图：描述程序运行期的进程、线程、对象实例，以及与此相关的并发、同步、通信等问题。
物理视图：描述软件如何安装并部署到物理的服务上，以及不同的服务器之间如何关联、通信。
场景视图：针对具体的用例场景，将上述 4 个视图关联起来，一方面从业务角度描述，功能流程如何完成，一方面从软件角度描述，相关组成部分如何互相依赖、调用。
在机械制图领域，一个立体的零件进行制图设计，必须要画三视图，即正视图、侧视图、俯视图，每张图都平面的，但是组合起来就完整地描述了一个立体的机械零件。4+1 视图模型也是通过多个角度描述软件系统的某个方面的抽象模型，最终组合起来构成一个软件完整的模型。
三视图中，有些部分是重复的，而正是这些重复的部分将机械零件不同视角的细节关联起来，使看图者准确了解一个机械零件的完整结构。软件建模的时候也是如此，作为设计者，也许你觉得用多个视图描述软件模型会重复，但是阅读你的设计文档的人，正是通过这些重复，才将软件的各个部分关联起来，对软件整体形成完整的认识。
我在前面说 4+1 视图模型是一种方法论的原因，就在于这 5 种视图模型主要指导我们应该从哪些方面去对我们的业务和软件建模。而具体如何去建模，如何画模型，则可以使用各种建模工具去完成，重要的是这些模型能够构成一个整体，从多个视角完整抽象软件系统的各个方面。
在实践中，通常用来进行软件建模画图的工具是 UML，建模的时候，也不一定要把 5 种视图都画出来。因为不同的软件类型其特点和设计关注点各不相同，只要能向相关人员准确传递出自己的设计意图就可以了。
UML 建模UML，即统一建模语言，是目前最常用的建模工具，使用 UML 可以实现 4+1 视图模型。这个名字的叫法也很有意思。
所谓统一，指的是在 UML 之前，软件建模工具和方法有很多种，最后业界达成共识，用 UML 统一软件建模工具。
所谓建模，前面已经说过，就是用 UML 对领域业务问题和软件系统进行设计抽象，一个工具完成软件开发过程中的两个客观存在的建模。
所谓语言，这个比较有意思，为什么一个建模工具被称为语言？我们先看下语言的特点，语言一则用以沟通，通过语言人们得以交流；二则用以思考，即使我们不需要和别人交流，仅仅一个人进行思考的时候，其实我们头脑中还是默默在使用语言，有时候甚至不知不觉说出来。
UML 也符合语言的这两个特点，一方面满足设计阶段和各个相关方沟通的目的；一方面可以用来思考，即使软件开发过程不需要跟其他人沟通，或者还没到沟通的时候，依然可以使用 UML 建模画图，帮助自己进行设计思考。
此外，语言还有个特点，就是有方言，而对于 UML，就我观察，不同公司，不同团队使用 UML 都有自己的特点，并不需要拘泥于 UML 的规范和语法，只要不引起歧义，在使用 UML 过程中对 UML 语法元素适当变通正是 UML 的最佳实践，这正是 UML 的“方言”。
具体如何使用 UML 画图建模，如何在不同的软件设计阶段用最合适的 UML 图形进行软件设计与建模，以及如何将这些模型图整合起来构成一个完整的软件设计文档，我会在下一篇文章中为你讲述。
小结很多做软件开发同学的职业规划都是架构师，那么设想这样一个场景，如果公司安排你做架构师，要你在项目开发前期进行软件架构设计，你该如何开展你的工作，你该如何输出你的工作成果，你如何确定你的设计是否满足用户需求，你是否有把握最后交付的软件是满足要求的，是否有把握让团队每个工程师清晰了解自己的职责范围并有效地完成开发工作？
架构师的核心工作就是做好软件设计，软件设计是软件开发过程中的一个重要环节。如何进行软件设计，软件设计的输出是什么？软件设计过程中，如何和各个相关方沟通，使软件设计既能满足用户的功能需求，又能满足用户的非功能需求，也能满足用户的成本要求？此外，还要使开发工程师、测试工程师、运维工程师能够理解软件的整体架构、主要模块划分、关键技术实现、核心领域模型，使他们能做好自己的工作，使得软件在开发之初就对软件未来蓝图有个清晰的认识，从而使整个软件开发过程处于可控的范围之内？
以上这些诉求可以说是软件开发管理与技术的核心诉求，这些问题搞定了，软件的开发过程和结果也就都得到了保证。而要实现这些诉求，主要的手段就是软件建模，以及将这些软件模型组织成一篇有价值的设计文档。
思考题回到我们上面描述的场景，如果公司安排你做架构师，你该如何开展你的工作，你向客户或者上司呈现的第一份工作成果是什么？你如何向团队开发人员呈现你的设计方案？
如果你暂时没有思路也不要紧，下一节我会为你完整描述一个解决思路。
欢迎你在评论区写下你的思考，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 12

提建议

答疑丨Java Web程序的运行时环境到底是怎样的？

09丨软件设计实践：如何使用UML完成一个设计文档？

 写留言

精选留言(23)

小伟
2020-02-04
一个合格的架构师必须是一个合格的产品经理、一个合格的研发、一个合格的测试，架构师的职责就是基于公司的战略和资源定位产品的核心价值、基于业务做技术选型、规范和指导研发、构建各维度的测试。如果我刚刚称为公司的架构师，我会和决策层统一公司的核心价值，并以PPT的形式体现承载价值的核心功能。达成一致后，召集全体研发、测试(如有)开会统一思想，包括产品功能、性能指标、版本管理、部署上线、交付时间等，都必须是可量化的。期间，可以发动群众集思广益，收集有建设性建议并和决策层讨论并最终定版，以产品功能说明书作为交付物。之后，基于终版功能及指标，做技术架构选择，以架构部署图作为交付物，并召集资深开会讨论，查缺补漏。之后，召集全体开发、测试(如有)开会，以使每个人都清楚自己的交付物和指标。之后，就可以开始功能迭代过程了。综上，核心价值确定第一位，统一思想第二位，技术选型第三位，其他都可以见招拆招，或直接水到渠成了。
展开
共 4 条评论
28
北天魔狼
2019-12-06
组织头脑风暴列出所有用户故事，根据用户故事业务关联划分领域模型，随后创建代码模型。这是我的理解结果，希望老师能予以点评
15
Paul Shan
2019-12-06
我想问一下李老师，像unix ，linux，等超大型的软件系统有没有这样的4+1的建模文档，多谢！
作者回复: 我不是很确定，Unix和Linux的情况是很不一样的，根据我在Apache开源社区开发的经验，大概率推测Linux是没有的。开源软件极少看到有完整软件建模的文档的，大部分关于设计的说明会通过论文的方式发表，里面也很少有常规意义上的软件模型。
9
escray
2020-09-15
工作了很多年，有时候真的会忘记初心，就是通过计算机软件高效、自动的解决现实中低效、手工的业务问题。在留言里面有同学提到，敏捷开发已经不需要建模和 UML 了，我之前也是这么想的，不过看了专栏的内容之后，我觉的软件建模和 UML 还是有必要的。敏捷开发把软件建模的过程变得简单、轻量级了一些，在敏捷开发中也会提到“隐喻”，这本身也是一种模型。而 UML 在敏捷中其实也是有用到的，只不过不在追求画图时候的精细和准确，更注重沟通，比如不是用软件，而是用白板来画图（拍照存档）。 4+1 视图模型仍然是软件开发中不可或缺的方法，也许不那么明显，有时候可能没有形成文档，但是在架构师或者程序员的脑子里，应该是有的。我觉的场景视图可能是 4+1 模型的核心，也可以看做是用例，或者敏捷开发中的用户故事。当然这一部分可能不是架构师的主要职责，而是产品经理或这是需求工程师的工作，但是架构师无疑是要理解用例场景的。 UML 的主要功能适用于沟通和思考。之前经历的一些项目，可能过于看重 UML 的精确程度，以至于花费了不少时间在画图上，而不是沟通和思考上。我感觉一张密密麻麻的 UML 图，其实很难做到“一图胜千言”的作用。如果公司安排我做架构师，我会先了解一下用户故事或者是用例场景，然后根据公司现有的人员、技术和资源，罗列一下可能的技术选型和架构设计，形成一份用以讨论的架构设计文档，呈现给领导或者客户，当然这两份文档是不一样的。面向开发团队的设计方案可能会更加细致一些，里面当然会有用 UML 绘制的 4+1 视图，但是估计会比较简单，能够沟通就可以了。
展开
5
vega
2019-12-08
关键是公司或者客户自己都不知道要什么吧……
共 1 条评论
4
魔曦
2020-03-22
架构师是介于实际问题与模型之间的一个角色，把客户需求转化为模型，然后把模型讲给开发，测试等。我理解产出需要按照纬度不同给出不同的图，比如面对客户让客户明白自己需求如何去解决落地，面对开发转化为工程设计如何落地，面对上级关注各方面进度等。沟通方向不一样，需要提供不同的视图。
4
张明云
2020-03-18
① 和产品一起梳理产品需求，明确产品功能和目标 ② 梳理框架图，抽象划分层次和模块 ③ 梳理核心流程图将框架中各层的各模块串起来 ④ 针对核心流程中关键的技术点做技术方案设计，包括技术方案验证、技术方案选型等，期间不定期共享技术方案给团队 ⑤ 基于方案设计，梳理出各技术点理论上能做到的指标 ⑥ 和开发人员一起落地技术方案，达成技术指标
展开
4
黄老板
2020-03-07
李老师，感觉这篇说的理论性的东西太理想化，现实开发中，一般就是写个功能需求文档，用rp原型软件画个界面原型，流程在说明一下，开发的几个人在一起碰一下，决定整体架构，功能划分下，带头的把大框架搭好，大家就开始干起来了，大部分都是这种情况，都是用敏捷开发的思路，最快的做出一个东西来，对领导也好交差，因为领导或者说客户他们一开始的时候常常也不知道自己需要的是什么，说了一堆也说不到重点，当你快速做了个东西后呈现在客户面前，这时候客户看着实物才会渐渐明确自己需要的是什么，他就会提很多修改的东西，然后开发小组根据客户反馈进行系统的迭代开发，当然这样会造成返工，但这几乎是不可避免的过程。
展开
共 2 条评论
4
卡特
2020-02-15
软件建模理论软件是为了解决问题领域而设计的软件系统 uml图是基本的建模方法 4+1视图场景视图逻辑视图物理视图开发视图过程视图是架构师输出的第一份工作成果
展开
1
靠人品去赢
2019-12-18
首先是技术选型，微服务，分布式，分流控制都要考虑，保证以后面对更多的挑战。第二是业务分析，不要陷入当前的业务，在更高的一个高度进行抽象，保证以后业务的可扩展性，现在不流行DDD吗第三架构设计，确定大体的结构最后是技代码设计，做到服务之间解耦
共 1 条评论
1
delete is create
2019-12-07
希望老师举个具体的案例来阐述建模，比如自己在开发什么软件什么功能的时候用到了建模这个方法用了比不用强在哪里等等，太形而上的东西像我这样刚入行的菜鸟领悟不了0.0
2
许童童
2019-12-06
现在公司都采用敏捷开发，很少画UML画了，我们都知道这样不好，但却没有人站出来，可能是缺少一个架构师这样的角色吧。
共 3 条评论
1
小鱼
2021-02-07
“在机械制图领域，一个立体的零件进行制图设计，必须要画三视图，即正视图、侧视图、俯视图”，老师，这点并不是哦，机械制图中，立体零件设计，一般只包含两个视图就够了，然后加上一些剖视图。极少数情况绘画三视图的。
作者回复: 谢谢指教~
共 2 条评论
Geek_9b9530
2020-12-13
把握需求边界，定义领悟模型，业务视图开发视图展示要完成的工作。
丁丁历险记
2020-10-18
这些东西不能乱搞，很容易的就设计过度了。
共 1 条评论
1
Geek_9f12f8
2020-06-09
UML能称为语言还有一个比较重要的特征，就是语言需要具备语言元素和约束元素的语法。UML的设计也依赖于此。
不记年
2020-01-31
理解需求后先出一份系统概要设计，向领导呈现技术选型和软件粗略的架构设计，然后是系统的详细设计，向同事呈现软件的详细接口设计，模块划分等
InfoQ_e077cb303519
2020-01-17
老师，架构设计和流程设计的工具一般都用什么
行者
2019-12-30
4 + 1视图模型法真赞；希望老师能在加餐中来一个完整的建模案例，相信对大家很有帮助。
堵车
2019-12-23
终于看到我想要看的东西，画图。做了5年的开发，还不知道怎么画图，要画哪些图。现在还在头疼，一个架构师要输出多少文档？接口文档，整体设计文档。。。
共 1 条评论

