CTO也糊涂的常用术语：功能模块、业务架构、用户需求、文档
潘加宇
功能模块、业务架构、需求分析、用户需求、系统分析、功能设计、详细设计、文档、业务、技术……很多被随口使用的名词，其实是含糊甚至错误的。
到底含糊在哪里，错误在哪里，不仅仅是新手软件开发人员糊涂，许多入行多年的老手也一样。虽然很多老手功成名就，挂着CTO、总架构师等研发线的最高头衔，但是心里对这些概念也是一团浆糊。
可能有的人会说，不会吧，这些牛人带团队做出了让公司赚钱的系统，怎么会不清楚呢，只不过表达出来和你的表达不同而已吧？我只能很诚恳地再说一遍：很多“牛人”真的不清楚。当然，搞不清楚不妨碍做出赚钱的系统，就像有的人不了解人体运行机制凭感觉也活到了一百岁。您也可以说“做出过赚钱的系统就行了呗，管他清楚不清楚呢！”，对对对，您说的都对，但不清楚也还是不清楚。
我先说一下我在《软件方法》一书中对软件建模工作流的划分：
A-业务建模——描述所研究组织内部各系统（人肉系统、电脑系统……）如何协作，使得组织可以为其他组织提供有价值的服务。
B-需求——描述为了解决组织的问题，所研究系统必须具有的表现——功能和性能。
C-分析——提炼为了满足功能需求，所研究系统需要封装的核心域机制。
D-设计——为了满足质量需求和设计约束，核心域机制如何映射到选定平台上实现。
以上四个工作流的名称使用了传统术语，也有一定的模糊性（特别是业务建模）。其实我觉得更贴切的名称是组织建模、需求建模、核心域建模、实现。如果您觉得业务建模、需求、分析、设计不好，直呼ABCD或改成阿猪、阿狗、阿鸡、阿鸭也无所谓。关键是要了解划分的依据：一个是研究范围，一个是研究内容。如图1：
|
工作流 |
范围 |
内容 |
|
A-业务建模 |
所研究组织和其他组织之间 所研究组织内部各系统之间 |
核心域 |
|
B-需求 |
所研究系统和其他系统之间 |
核心域 |
|
C-分析 |
所研究系统内部 |
核心域 |
|
D-设计 |
所研究系统内部 |
非核心域 |
图1 不同工作流的研究范围和内容
再说一下核心域和非核心域的概念。一个软件系统封装了若干领域的知识，其中一个领域的知识代表了系统的核心竞争力，是系统和其他系统区分的关键所在。这个领域称为"核心域"，其他领域称为"非核心域"。更通俗的说法是"业务"和"技术"，但使用"核心域"和"非核心域"更严谨。核心域不一定是物流、医疗、金融等非计算机领域，也可以是计算机和软件领域。图2展示了不同系统的核心域和非核心域概念：
|
系统 |
核心域概念 |
非核心域概念 |
|
文档处理器（如Microsoft Word） |
文档、页、行、字…… |
CStringArray、CFileDialog、MSXML…… |
|
电子商务网站（如淘宝网） |
商品、订单、会员…… |
</div>、ActionForm、SessionFactory…… |
图2 不同系统的核心域、非核心域概念
好，根据以上的知识，我们来逐一剖析这些术语，可能有好几十个。
术语01：功能模块
评价：“功能”属于模糊术语，“模块”属于模糊术语，“功能模块”属于错误术语。
功能（Function）。当我们说起这个词的时候，研究对象一般是系统。对于组织，一般说“组织的服务”，对于类，一般说“类的操作”。所以，“功能”属于“B-需求”的范畴（功能需求），描述系统作为一个整体为其他系统提供的服务，把其他系统给它的输入变成其他系统所需要的输出。
但是，“功能需求”仍然不够精确。例如，以自助柜员机（ATM）为研究对象，“取现金”是“功能”，“登录”也是功能，“计算手续费”也是“功能”，到底“功能”有多大？用例的术语要严谨得多。“取现金”是一个用例，“登录”是用例中的一个回合，“计算手续费”是一个步骤。
模块（Module）。当我们说起这个词的时候，研究对象一般是系统。模块表示系统的组成部分，属于“C-分析”和“D-设计”的范畴。这个词也是模糊的。这个模块是一个控件？一个类？若干个类形成的组件？
如果说“功能”和“模块”是模糊的，那么“功能模块”就是错误的，这个词混淆了系统外部和内部的区别，需求和设计的区别。
“功能”是系统对外提供的服务，“模块”是系统的内部结构。连起来说“功能模块”，意味着在意识里认为“功能”和“模块”有直接的映射关系，甚至认为“模块”是属于某个“功能”的模块，是为了完成某个“功能”而存在的。
这样的认识是错误的。如图3所示，完成某个“功能”需要若干“模块”的协作，而某个“模块”也会参与完成若干“功能”，例如可以看出“模块6”被反复使用了很多次。如果将“功能”和“模块”直接映射，系统内部将出现大量冗余。
图3 “功能”和“模块”的映射是多对多的
人体就是一个系统，基本功能有走路、跳跃、吃饭等，但是设计人体结构时，不能从外部直接映射到内部，得到人体由“走路模块”、“跳跃模块”、“吃饭模块”组成。人体的“模块”是五官四肢和内脏，还有最关键的——“大脑”。不管是走路、跳跃还是吃饭或者将来发展出更多的“功能”，都由这些“模块”协作完成。
那么，那些经常被称为“功能模块”的东西，应该怎么称呼合适呢？图4是百度“功能模块”得到的排第一位的图片：
图4 百度“功能模块”得到的排第一位的图片，来自http://www.think58.com/asp/9182.html，非UML图
从图4得知，“商品销售管理系统”有很多功能，其中一部分是给用户使用的，另一部分是给管理员使用的，所以很多人会说“本系统分为两大功能模块——用户模块和管理员模块”，但是这样的说法在意识里不知不觉犯了从外直接映射内部的错误，如图5。
图5 不知不觉从外部映射到内部
还是用人举例。人有很多功能，有些是为老板提供的，有些是为老婆提供的，还有些是为老爸老妈提供的。按照图4的意思，人可以切割成“老板模块”、“老婆模块”……人体确实可以根据内部的耦合和内聚情况切割成不同层次的“模块”（细胞→组织→器官→子系统），但是和外面的切割没有直接的映射关系。为老板服务也好，为老婆服务也好，没有强大的血液循环子系统（心脏、血管）和神经系统（脑、脊髓、各种神经）都是搞不定的。
设想食人族把一个人大卸八块（对，模块的块），分赃时会怎么说？“来，左腿归你，下水归我”，还是“走路功能归你，吃饭功能归我”？
如果要描述若干功能的集合，更贴切的术语应该是“功能包”，如图6所示。
图6 用需求包来表达功能集合
当然，如果您硬要说，老子就喜欢叫“功能模块”，那也可以，关键是要了解我上面说的道理。
访问网址http://www.umlchina.com/book/quizall1to8.htm或扫描以下二维码自测你的水平。共108道题，做完后会给出分数。能答对60道就算不错了！
术语02：业务架构
评价：“业务”属于模糊术语，“架构”属于模糊术语，“业务架构”属于模糊术语。
业务（Business）。“业务”这个词在软件开发团队中使用得很频繁，例如“我是一名业务架构师”、“我们要了解业务”等等，但是往往说话的人未必真的理解话中的“业务”具体指什么。
有时候“业务”指的是内容上的划分，含义是“核心域”。
例如，一个餐馆系统，订单和菜品的关系属于“业务知识”，折扣的计算规则属于“业务规则”，如图7所示。
图7 餐馆系统需要封装的“业务”——核心域类图
此时，和“业务”相对应的就是“技术”了。开发人员假装谦虚“我是做技术的，业务不太懂唉”，就是这个意思。甚至有的开发人员在潜意识里是这样划分的：
我懂且我感兴趣的知识→技术；（我是一名Java程序员，Java编码是技术）
我懂但不感兴趣的知识→业务；（下单、收银、配送我懂一些，但不感兴趣，这些是业务）
我不懂但感兴趣的知识→高科技；（我不懂深度学习，但很感兴趣，哇塞，高科技）
我不懂且不感兴趣的东东→忽悠。（我不懂UML建模，也不感兴趣，妈的，忽悠）
有时候“业务”指的是范围上的划分，含义是“组织级别”。例如，“业务建模”说的是组织级别的建模、“业务用例”说的是组织为其他组织提供的服务，“业务流程”说的是组织内各个系统之间协作的流程。如图8，表达了餐馆的“业务流程”。
图8 餐馆组织的“业务”流程
此时，和“业务”相对应的就是“系统”了。
架构（Architecture）。“架构”这个词被滥用得厉害，已经达到一砖头砸死十个架构师的地步。Martin Fowler曾经在他的书“Patterns of Enterprise Application Architecture”中写道：
The software industry delights in taking words and stretching them into a myriad of subtly contradictory meanings. One of the biggest sufferers is "architecture."
软件业乐于做这样的事——找一些词汇，并引申出大量微妙而又互相矛盾的含义。一个最大的受害者就是“架构”。
维基百科中这样描述“架构”：
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
我的归纳：架构是多个系统内部共有的抽象机制。
要点一：内部。系统提供的各种功能，不属于“架构”。要点二：共有。架构是一种复用机制。它独立于单个系统，围绕它可以组装成系统的家族。
图9是现在常提到的一个架构。可以断定，我们会在很多软件系统中发现这样的机制。图9表达的是不同领域（UI、Database、核心域……）之间交互的机制。不管系统的核心域是哪一个（保险、物流、医疗），这样的机制都可以存在。
图9 域之间的架构，来自taimila.com，非UML图
图10也是架构，也可以在千万个软件系统中发现这样的机制。相对于图9，图10表达的是某个领域内部各种领域概念的关系。不管将核心域概念映射到哪些非核心域上（Android还是iOS，Vue还是React）得到系统，这样的机制都可以存在。
图10 域内部的架构
这里再啰嗦几句。在一些软件开发大会常可以看到这样的场景：某电子商务网站的架构师上台讲了一通，接着某视频网站的架构师上台也讲了一通，咦，两个演讲内容如此相似？原来，他们讲的都是自己系统中各域之间的机制（类似图9），而不是核心域内部的机制（类似图10）。究其原因也许并非不为，而是不能——开发人员对自己所开发系统的核心域研究太浅。许多“网红程序员”在网上谈论的内容大多是某种语言或框架的新特性，少有探讨他当前所开发系统的复杂领域逻辑，也是同样的原因：并非不为，而是不能。
业务架构。根据以上讲述，这个词有两种含义。
含义一：组织的内部机制。此时，“业务”作“组织”解。图8就描述了这样的机制。维基百科采用的就是这种含义，如图11。此时业务架构师应该负责的是“A-业务建模”的工作。
图11 维基百科上关于业务架构的描述
我们再来看一些公司招聘“业务架构师”（Business Architect）的描述，有的岗位要求还比较贴近“A-业务建模”，如图12。
图12 业务架构师岗位描述1，来自拉勾网
也有不知所云的岗位要求，如图13。
图13 业务架构师岗位描述2，来自拉勾网
含义二：系统内部的核心域机制。此时，“业务”作“核心域”解。图10就描述了这样的机制。此时业务架构师应该负责的是“C-分析”的工作。
遗憾的是，在招聘网站上搜不到符合这个含义的“业务架构师”岗位。搜“架构师”可发现其岗位要求覆盖了“C-分析”和“D-设计”。上文已经说过，绝大多数的“架构师”熟悉的是“D-设计”的工作（图9），不擅长“C-分析”的工作（图10）。
访问网址http://www.umlchina.com/book/quizall1to8.htm或扫描以下二维码自测你的水平。共108道题，做完后会给出分数。能答对60道就算不错了！
术语03：用户需求
评价：“用户”属于模糊术语，“需求”属于明确术语，“用户需求”属于错误术语。
用户（User）。首先，用户默认是人，没有称某个软件系统为用户的——“本系统的另一个用户是第三方支付系统”；其次用户是和所研究系统有交互的人。例如，我正在用Word写这篇文章，我是Word的用户。以上是最常见的理解。
有时“用户”也会用在根本没有人机交互的地方，如图14。一个定时收集信息的系统，根本不需要和人交互，但需求人员也会说“用户是怎么要求的？多长时间收集一次？速度要多快？源格式和目标格式是怎样的？”此时，“用户”不是指和所研究系统交互的人，而是系统所服务的目标组织的某个负责和开发团队接口的人。例如，假设这个系统为某市国税局服务的，需求人员刚才说的“用户”可能是国税局信息中心的副主任。怎样称呼这位副主任才正确，后文再说。
图14 无人参与交互的收集过程
“用户”一词存在的问题：
（1）很多时候我们口中的“用户”是随意推测的。
我们来看图8的餐馆的例子。我们把它搬到图15。假设图15是餐馆的现状，餐馆的老板希望在此现状之上进一步改进。需求人员很容易先入为主，认定上面的人就是新系统的“用户”，然后逐个找这些“用户”调研。
图15 餐馆的现状业务流程
这样的先入为主是不对的。也许餐馆老板希望看到的改进如图16所示。从图中可以看到，领位员这个岗位都不需要了，还找他调研个啥。如果连服务员都可以不要，老板可能觉得更爽。
图16 对餐馆流程的一种改进
（2）“用户”混淆了演员和观众。
我们先来看用例（Use Case）的一些概念。如图17所示，用例把软件系统看作一部电影，演员（Actor，执行者）在台上表演，观众（Stakeholder，涉众）在台下看，观众按照他们的地位排排坐。演员在台上表演什么是由观众的口味决定的，先照顾前排的观众，如果有余力，再照顾后排的观众。
图17 演员（执行者，Actor）在台上表演，观众（涉众，Stakeholder）在台下看
用例使用“执行者”（Actor）和“涉众”（Stakeholder）代替了原来的“用户”，这是一个非常大的突破。“用户”这个词混淆了演员和观众的区别。过去经常说“找用户调研需求”，这是错误的。所谓“用户”，就是上台表演的人类演员。找用户调研，相当于找演员问剧本应该是什么内容，岂不是很荒谬？剧本应该由编剧向观众调研编写出来，然后由各路演员在台上演绎。
演员如果是人类，那么在观众席上也会有一个位置，不过在第几排就不知道了。范冰冰这样的大咖，可能有能力影响剧本的内容，跑龙套的就算了吧。
在台上当“用户”当得越欢的涉众，往往在涉众排行榜上排位越靠后。您想想，整天操作电脑搞得手僵脖子硬的“用户”，有几个是职位高的呢？真正位高权重的涉众，虽然偶尔也会上台表演，但更多时候是坐在台下看戏。建模人员如果过多地关注“用户”，花在重要的前排涉众身上的时间可能就不够了。
像“用户故事”这样的方法在开发一些面向大众的互联网系统时还能应付，因为这类系统的执行者往往属于前排涉众，以上问题就被掩盖了。如果开发涉众较多、利益冲突微妙的系统，应该采用用例这样更严谨的需求技能。例如做一个手机游戏，重点调研玩家这个“用户”是可以的，做一个某单位的柜台系统，也重点调研窗口工作人员（希望干活越少越好），那背后的领导和其他同事就遭殃了。
另外，现在的系统做出来，越来越多的接口不是面向人类的，而是面向另一个软件系统，也就是说没有“用户”。两个电脑系统交互的需求，难道就不用做了，或者可以随便做？非也。那只是相当于上台表演的不是人，是功夫熊猫、变形金刚和喜羊羊灰太狼，但是台下对表演说好说坏的观众依然是人。建立“执行者和系统在台上表演，涉众在台下看表演”的概念，在执行者为非人系统时对捕获需求很有帮助。
（3）“用户”是拒绝深入思考的遮羞布。
即使是演员和前排观众重叠的系统，“用户”也是一个阻拦需求人员深入思考的词汇。许多产品经理把“用户”挂在嘴边，“要从用户的角度思考”，“用户满意的才是好产品”等等，甚至还有“乔布斯不在意用户的意见”等奇谈怪论。问题来了，谁是用户？
一个老头找到PS可乐公司，告诉他们的主管，“我可是你们的忠诚客户啊！我喝过的可乐罐排成线，可以从苹果园排到通州（北京从西到东）。现在我老了，我对你们的可乐下一个版本提出如下要求：第一，我有胃病，下一个版本不要有这么多气；第二，我有糖尿病，下一个版本里面不要有糖。”PS可乐公司的主管很感动，哇，这么棒的顾客，把要求提得那么具体，省下好多我们调研需求的时间，好，下个版本就这么办！
可惜，现实生活中不会有这样的场景。老头老太太可以买可乐喝，甚至可以买给自己的宠物喝，PS可乐公司不会拦着。问题在于，老头老太太提的要求，或者为他们的宠物提的要求（注意用词：是要求，不是需求），PS可乐公司不会放在重要的位置来考虑，因为PS可乐的目标人群是青少年。可惜，很多时候我问需求人员：“可乐卖给谁？”得到的回答大多是“卖给消费者”，“卖给想喝可乐的人”等对做出好卖的可乐没有帮助的、正确而无用的废话。
我在《软件方法》中，用“老大”取代了“用户”。“老大”是一个真实存在的具体的人。定位“老大”的具体方法参见《软件方法》第2章，和Persona方法类似。但是Persona是虚构一个“用户画像”，说白了也是鼓励需求人员逃避深入第一线调研的辛苦，安心闭门造车。例如，为女性做一个产品，建模人员深入第一线调研，面对的调研对象是一个个具体的女性。如果建模人员把调研的精力花在罗玉凤身上，留给林志玲的精力就不多了，所以必须思考罗玉凤更像老大还是林志玲更像老大的问题。相比起来，关在办公室随意捏造一个符合自己要求的“女性”省事多了。如果满足于Persona，归根结底还是在内心里没有认识到深入第一线调研的重要性。
“老大”的头脑是一块块的战场，所研发的系统是一支军队。研发团队的领导是军队指挥官，他负责找到自己的军队最值得投入的战场，指挥军队和敌人厮杀，占领战场，或者防守住敌人的进攻。战局是残酷的。您手上的三万红军下一步应该杀向哪里，可选项其实少之又少，您必须竭尽全力把这个战场找出来。可惜，许多人低估了现实的残酷，意淫自己手里有百万大军，爱杀往哪里就杀往哪里。
图18 在老大的大脑里厮杀
需求（Requirement）。明确术语，不再单独阐述。
用户需求。错误术语。需求指系统对外提供的功能性能，如果要在“需求”前面加一个定语，这个定语是“系统”——“系统的需求”。
系统的需求就像电影的剧本，规定了电影拍出来必须满足的内容，它是平衡了各种观众的口味（先照顾第一排观众，再照顾第二排……）得到的结果。对所有观众、演员来说，剧本就在那里，不会因为某个观众不喜欢其中某个情节而变化，也不会因为暂时还没有找到演员来拍成电影而变化。所以，不存在什么“用户需求”、“设计需求”、“架构需求”、“开发需求”、“编码需求”等东西。需求不是你的、我的、他的，是系统的，是你我他最终达成的关于系统的一份契约。
那么，“用户”后面能跟什么呢？可以跟“要求”。更严谨的术语是“涉众利益”。需求像电影剧本，涉众像电影观众。剧本只有一份，观众却是多种多样，不同观众的欣赏角度和口味不同。鲁迅说过：一部红楼梦，经学家看见《易》，道学家看见淫，才子看见缠绵，革命家看见排满，流言家看见宫闱秘事。
软件系统也是如此。例如一个生产执行管理系统，老大制造部王部长关注的是“缩短从接到市场部订单到交付产品的时间周期”，车间工人更关心“我这个岗位的工作量会不会增加”，库管员可能担心“以后不好搞手脚”。系统的需求首先要照顾王部长的利益，在不损害王部长利益的前提下，还有余力的话再照顾车间工人和库管员。对于实在照顾不到的后排涉众，很多时候只好抱歉了，这个系统可能会损害你的利益。
软件的需求规约相当于电影剧本。电影剧本不是由观众直接提供，而是由编剧根据不同观众的口味编出来的。同样，软件需求不是由涉众直接提供的，而是由需求人员综合不同涉众的利益来决定的。涉众没有资格提供需求。
系统的需求是平衡各种涉众利益得到的，不由单一涉众决定。以ATM机为例，如果需求人员询问ATM机的执行者储户“取款机应该怎么做你觉得最好”，储户回答大实话“最好像我家抽屉一样拉开就拿，喏，把我家里的抽屉拿去做原型”，需求人员显然不能把这个“抽屉”当真，只需要把“抽屉”背后的涉众利益提炼出来——储户希望操作次数尽可能少一些。最终系统的需求有多少尊重了这个利益，就要看储户在涉众排行榜上的排位了。
拿患者和医生类比也可以帮助理解。患者到医院对医生说“我腿疼，可能得了腿癌，我要做放疗”，医生就给他做放疗？显然不是这样，医生只能把患者所说的一切当成素材，按照成熟的套路，该做什么检查就做什么检查，该如何治疗就如何治疗。
很多时候我们想涉众调研时，涉众直接给出解决方案——“我要一个像某某软件那样的！”如果你真的按照他说的做了，他用的时候又不满意了，而且他的其他同事更不满意。然后我们还委屈呢，都是按照当时开会时你说的做的，还有录音为证！
了解到“涉众无资格提供需求，和涉众交流的内容应该聚焦于涉众利益”，可以帮助我们少犯错误。
访问网址http://www.umlchina.com/book/quizall1to8.htm或扫描以下二维码自测你的水平。共108道题，做完后会给出分数。能答对60道就算不错了！
术语04：文档
评价：“文档”属于模糊术语。
先列出使用“文档”的一些话语：
*你们怎么一上手就写代码，连个文档都没有！
*你现在在做什么？我在写文档。
*代码就是文档。
从以上话语可以看出以下问题：
（1）在许多软件开发人员的大脑里，“文档”的意思就是“代码之外的其他工件”。由于缺乏软件工程方面的基本知识，对之前提到的“A-业务建模”、“B-需求”、“C-分析”、“D-设计”等工作流没有概念，只好把软件开发工作分为“写代码”和“写文档”两部分。（其实，就连什么叫“代码”，很多人也是糊涂的，这一点后面再说。）
（2）软件开发人员一旦把工件简单分割为“代码”和“文档”，还会导致这样的误解：认为“文档”只不过是“代码”的一种比较概要或比较形象的表现形式，不同的“文档”代表着“代码”的不同视图，可以让开发人员从不同的视角观察代码，这样就便于人脑把握代码的复杂性。如图19所示。
图19 误解：文档只是代码的视图
这种误解不只“普通”的开发人员会有。Martin Fowler所著的UML畅销书《UML精粹》，认为UML有三种用法：草稿、蓝图和编程语言，也是仅从编码的角度来说的。从Fowler写作的其他书籍《重构》、《企业应用架构模式》、《分析模式》等可以知道，他的研究工作集中在分析设计工作流，在业务建模和需求方面研究不多。
这样的误解就会导致推论：只要“代码”写得自己“会说话”，那么“代码就是文档”，“文档”就不需要了。本来“文档”就是“代码以外的其他东西”，这么一推，就变成了“代码就是一切”。
（3）把“文档”当作“代码”的视图还会带来下面这种思维颠倒：先拍脑袋实现，然后再从实现反推其他工作流的内容。例如下面的对话：
A：这个不应该是系统的用例（如果您不理解什么叫“用例”，就先把它理解为“功能”好了）。
B：是的！我都写好了，运行一下给你看，这个系统确实提供了这个用例。
是否系统的用例应该以“好卖”来判断。权衡涉众利益之后觉得应该有，系统就有，不该有就没有，而不是我写好了代码，所以就应该有。
A：这两个类关系不应该是泛化，而是关联。
B：是泛化，不信我打开代码给你看，或者逆向工程转出类图给你看。
是否泛化关系应该以“符合领域内涵”来判断，而不是先写好代码“人是猪的一种”（肯定编译通过），再用写好的代码来证明“人是猪的一种”。
（4）“文档”还意味着它和“代码”使用的可能是不同的工具写出来的。在Visual Studio、Eclipse里面写出来的叫“代码”，在Word、wiki、Visio、EA等等里面写或者画出来的叫“文档”。
正确的理解是：
不同工作流产出的工件之间的区别不在于形式，而在于思考和表达的内容，如图20所示。
图20 建模工作流思考内容
如果清楚了解“区别在于内容”这一点，就知道“我在写文档”这样的话只是表达“我正在用文档编辑工具在工作”，没有其他意义。你在写什么文档？“业务建模”？“需求”？“分析”？“设计”？我不写，我画图难道不可以吗？我不写不画，我用语音清楚地表达出组织的流程，不可以吗？更有意义的说法应该是“我在做业务建模”。如果说“文档”二字可以给您带来不可替代的快感，可以说“我在写业务建模文档”。
内容和形式的组合是灵活的。很流行的“代码就是设计”这句话的意思就是，设计工作流目前推荐的做法是不需要画UML图或者写“设计文档”，直接用源代码来表达设计模型。编码本身就是一种建模工作。计算机运行的是二进制指令，源代码实际上也是“模型”。之所以被称为“源代码”，是因为它是人脑需要编辑的最低形式模型（编辑完这个就好，后面的事情就可以交给计算机了！）。这个最低形式模型随着时代的发展不断变化。
如图21所示，最初的源代码是机器语言。程序员在纸带或卡片上打孔来表达0和1。后来发现这样太累了，于是发明了一些助记符，这就是汇编语言。今天会有开发人员故意装×，“这些我不太懂唉，我是做底层的，用C编码”，可是C语言却被归类为“高级语言”，因为类似C这样的语言出现的时候，大多数程序员编辑的是汇编语言，C相对于汇编来说，当然很高级。今天的一名企业应用程序员，最终需要编辑的可能有HTML、CSS、JavaScript、Java、配置脚本、SQL等，这些就是现在的“源代码”的形式。
图21 “源代码”的发展历程
从图21中的“历史进程”来看，大趋势是人脑要编辑的“源代码”离计算机原来越远，离领域越来越近。至于最终什么样的具体形式能成为下一形式的代表，只好看各种语言的“个人奋斗”了。
同理，如果人脑只需要编辑UML模型就可以实现系统，那么“模型就是源代码”。例如用带有设计级调试和强大代码生成能力的工具IBM Rational Rhapsody开发实时嵌入系统，在配置好和IDE的集成之后，人脑只需要编辑和调试UML模型（主要是类图和状态机图），就可以实现系统，不需要在IDE里敲字符。感兴趣的读者可以自己去看Rhapsody附带的例子。
“代码就是设计”可以，那么“代码就是需求”可以吗？当然也可以。例如，把整个系统看作一个类，那么这个类的操作就是系统的需求，因为它表达的是系统作为整体提供的服务。
我们在使用UML建模的时候，各种建模元素和建模内容也是灵活匹配的。例如，状态机图，可能一看到就想起分析设计，其实也可以用来表达需求。图22把“电视”作为整体来画状态机，表达的就是“电视”的需求。
图22 用状态机图表达电视的需求（读者可以自行思考图中？处应该写什么。看起来一目了然，其实写对不容易。）
当然，不同的内容有推荐的形式。各建模工作流可以选用的建模图形以及推荐用法如图23所示。
图23 可选和推荐的建模元素用法（●表示优先使用，√表示可以使用 ）
访问网址http://www.umlchina.com/book/quizall1to8.htm或扫描以下二维码自测你的水平。共108道题，做完后会给出分数。能答对60道就算不错了！
本文的pdf文件排版更佳，图片更清晰。请在http://www.umlchina.com/book/ctoterm.pdf下载。
UMLChina提供建模系列服务
（1）评审服务。评审开发团队做出的各种模型，给出改进建议。
（2）建模服务。提炼开发团队手中乱七八糟的各种素材，得到用UML表示的规范的业务建模模型、需求模型和分析模型
（3）项目全程建模指导服务。
从（1）到（3）价格递升。具体价格根据项目具体情况单独商议。建议先看看《软件方法》了解我们所提供的服务之后，再提具体要求。
提供增值税专用发票或增值税普通发票，可签保密协议。
联系方法：
微信：18758097122
QQ：1493943028
电子邮箱：umlchinacourse@163.com
电话：18758097122
UMLChina提供建模示范视频
视频内容：针对某个项目展现从业务建模到需求、分析和设计的真实操作。
我们会不定期发布各种类型项目和各种建模工具的示范视频片段。如果需要完整视频（格式DivX）需付费，具体价格见下表。
购买方法：
微信：UMLChinaSicilia
QQ：1493943028
电子邮箱：umlchinacourse@163.com
电话：13588070795
因录制视频需要投入大量精力，为避免有些视频录制后购买者太少导致精力浪费，以后的视频都采用预订方式。先交纳50元作为订金，如果同一视频预订人数超过8人，就启动该视频的录制。补齐全款后，交付视频。以预订方式购买的同学，每个视频的价格优惠20元。
|
番号 |
名称 |
时长（分） |
mp4大小(G) |
价格(元) |
公开片段（实际视频比腾讯的画质好很多！） |
|
EA-001 |
三方采购平台+EA13.5 |
81 |
0.77 |
180 |
|
|
EA-002 |
生产执行系统MES+EA13.5 |
160 |
1.19 |
220 |
业务用例图业务序列图片段 |
|
ST-001 |
生产执行系统MES+StarUML2.8.1 |
135 |
1.99 |
210 |
业务用例图业务序列图片段 |
|
EA-003 |
房产中介考勤系统+EA13.5 |
89 |
1.39 |
185 |
分析类图和序列图片段 |
|
EA-004 |
会议室管理系统+EA13.5 |
95 |
2.87 |
190 |
|
|
EA-005 |
微信餐馆+EA13.5 |
175 |
4.92 |
240 |
愿景业务用例图现状业务序列图片段 |
|
以下为尚未录制，可预订，预订人数足够才开始录制。 |
|||||
|
RH-001 |
番茄钟+Rhapsody 8.3 |
预计90 |
|
200 |
|
|
VP-001 |
微信餐馆+VP14.2 |
预计160 |
|
220 |
|
EA起始模板模型：http://www.umlchina.com/training/myproject.rar
StarUML起始模板模型：http://www.umlchina.com/training/myprojectstaruml.rar
注：视频是不需要声音讲解的。在视频的关键地方我们加上《软件方法》（http://www.umlchina.com/book/softmeth.htm）相应内容或UML全程实作幻灯片（http://www.umlchina.com/training/slide.htm）的提示。如果您看不明白，请务必再复习《软件方法》或幻灯片。
如需发票，需再加发票及快递费35元。
付费后，我们会制作好专为您提供的视频，告诉您下载地址。 我们在发给购买者的每个视频中嵌入了购买者特有的信息，所以该视频请仅限于您自己使用，不要外流，谢谢！
如果您需要某种特定类型项目和特定工具的建模示范视频而我们还没有发布，可以找我们定制，费用另议。