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

我想问一下李老师，像unix ，linux，等超大型的软件系统有没有这样的4+1的建模文档，多谢！

“在机械制图领域，一个立体的零件进行制图设计，必须要画三视图，即正视图、侧视图、俯视图”，老师，这点并不是哦，机械制图中，立体零件设计，一般只包含两个视图就够了，然后加上一些剖视图。极少数情况绘画三视图的。

一个合格的架构师必须是一个合格的产品经理、一个合格的研发、一个合格的测试，架构师的职责就是基于公司的战略和资源定位产品的核心价值、基于业务做技术选型、规范和指导研发、构建各维度的测试。 如果我刚刚称为公司的架构师，我会和决策层统一公司的核心价值，并以PPT的形式体现承载价值的核心功能。达成一致后，召集全体研发、测试(如有)开会统一思想，包括产品功能、性能指标、版本管理、部署上线、交付时间等，都必须是可量化的。期间，可以发动群众集思广益，收集有建设性建议并和决策层讨论并最终定版，以产品功能说明书作为交付物。之后，基于终版功能及指标，做技术架构选择，以架构部署图作为交付物，并召集资深开会讨论，查缺补漏。之后，召集全体开发、测试(如有)开会，以使每个人都清楚自己的交付物和指标。之后，就可以开始功能迭代过程了。 综上，核心价值确定第一位，统一思想第二位，技术选型第三位，其他都可以见招拆招，或直接水到渠成了。

组织头脑风暴列出所有用户故事，根据用户故事业务关联划分领域模型，随后创建代码模型。这是我的理解结果，希望老师能予以点评

工作了很多年，有时候真的会忘记初心，就是通过计算机软件高效、自动的解决现实中低效、手工的业务问题。 在留言里面有同学提到，敏捷开发已经不需要建模和 UML 了，我之前也是这么想的，不过看了专栏的内容之后，我觉的软件建模和 UML 还是有必要的。 敏捷开发把软件建模的过程变得简单、轻量级了一些，在敏捷开发中也会提到“隐喻”，这本身也是一种模型。而 UML 在敏捷中其实也是有用到的，只不过不在追求画图时候的精细和准确，更注重沟通，比如不是用软件，而是用白板来画图（拍照存档）。 4+1 视图模型仍然是软件开发中不可或缺的方法，也许不那么明显，有时候可能没有形成文档，但是在架构师或者程序员的脑子里，应该是有的。 我觉的场景视图可能是 4+1 模型的核心，也可以看做是用例，或者敏捷开发中的用户故事。当然这一部分可能不是架构师的主要职责，而是产品经理或这是需求工程师的工作，但是架构师无疑是要理解用例场景的。 UML 的主要功能适用于沟通和思考。之前经历的一些项目，可能过于看重 UML 的精确程度，以至于花费了不少时间在画图上，而不是沟通和思考上。我感觉一张密密麻麻的 UML 图，其实很难做到“一图胜千言”的作用。 如果公司安排我做架构师，我会先了解一下用户故事或者是用例场景，然后根据公司现有的人员、技术和资源，罗列一下可能的技术选型和架构设计，形成一份用以讨论的架构设计文档，呈现给领导或者客户，当然这两份文档是不一样的。 面向开发团队的设计方案可能会更加细致一些，里面当然会有用 UML 绘制的 4+1 视图，但是估计会比较简单，能够沟通就可以了。

架构师是介于实际问题与模型之间的一个角色，把客户需求转化为模型，然后把模型讲给开发，测试等。我理解产出需要按照纬度不同给出不同的图，比如面对客户让客户明白自己需求如何去解决落地，面对开发转化为工程设计如何落地，面对上级关注各方面进度等。沟通方向不一样，需要提供不同的视图。

① 和产品一起梳理产品需求，明确产品功能和目标 ② 梳理框架图，抽象划分层次和模块 ③ 梳理核心流程图将框架中各层的各模块串起来 ④ 针对核心流程中关键的技术点做技术方案设计，包括技术方案验证、技术方案选型等，期间不定期共享技术方案给团队 ⑤ 基于方案设计，梳理出各技术点理论上能做到的指标 ⑥ 和开发人员一起落地技术方案，达成技术指标

李老师，感觉这篇说的理论性的东西太理想化，现实开发中，一般就是写个功能需求文档，用rp原型软件画个界面原型，流程在说明一下，开发的几个人在一起碰一下，决定整体架构，功能划分下，带头的把大框架搭好，大家就开始干起来了，大部分都是这种情况，都是用敏捷开发的思路，最快的做出一个东西来，对领导也好交差，因为领导或者说客户他们一开始的时候常常也不知道自己需要的是什么，说了一堆也说不到重点，当你快速做了个东西后呈现在客户面前，这时候客户看着实物才会渐渐明确自己需要的是什么，他就会提很多修改的东西，然后开发小组根据客户反馈进行系统的迭代开发，当然这样会造成返工，但这几乎是不可避免的过程。

关键是公司或者客户自己都不知道要什么吧……

希望老师举个具体的案例 来阐述建模，比如自己在开发什么软件什么功能的时候用到了建模这个方法 用了比不用强在哪里等等，太形而上的东西像我这样刚入行的菜鸟领悟不了0.0