所在位置:UML新闻 - 内容 论坛精华    
CTO也糊涂的常用术语:功能模块、业务架构、用户需求、文档

[2018/5/30]

作者 潘加宇

功能模块、业务架构、需求分析、用户需求、系统分析、功能设计、详细设计、文档、业务、技术……很多被随口使用的名词,其实是含糊甚至错误的。

到底含糊在哪里,错误在哪里,不仅仅是新手软件开发人员糊涂,许多入行多年的老手也一样。虽然很多老手功成名就,挂着CTO、总架构师等研发线的最高头衔,但是心里对这些概念也是一团浆糊。

可能有的人会说,不会吧,这些牛人带团队做出了让公司赚钱的系统,怎么会不清楚呢,只不过表达出来和你的表达不同而已吧?我只能很诚恳地再说一遍:很多"牛人"真的不清楚。当然,搞不清楚不妨碍做出赚钱的系统,就像有的人不了解人体运行机制凭感觉也活到了一百岁。您也可以说"做出过赚钱的系统就行了呗,管他清楚不清楚呢!",对对对,您说的都对,但不清楚也还是不清楚。

我先说一下我在《软件方法》一书中对软件建模工作流的划分:

A-业务建模——描述所研究组织内部各系统(人肉系统、电脑系统……)如何协作,使得组织可以为其他组织提供有价值的服务。
B-需求——描述为了解决组织的问题,所研究系统必须具有的表现——功能和性能。
C-分析——提炼为了满足功能需求,所研究系统需要封装的核心域机制。
D-设计——为了满足质量需求和设计约束,核心域机制如何映射到选定平台上实现。


以上四个工作流的名称使用了传统术语,也有一定的模糊性(特别是业务建模)。其实我觉得更贴切的名称是组织建模、需求建模、核心域建模、实现。如果您觉得业务建模、需求、分析、设计不好,直呼ABCD或改成阿猪、阿狗、阿鸡、阿鸭也无所谓。关键是要了解划分的依据:一个是研究范围,一个是研究内容。如图1:

图1 不同工作流的研究范围和内容

再说一下核心域和非核心域的概念。一个软件系统封装了若干领域的知识,其中一个领域的知识代表了系统的核心竞争力,是系统和其他系统区分的关键所在。这个领域称为"核心域",其他领域称为"非核心域"。更通俗的说法是"业务"和"技术",但使用"核心域"和"非核心域"更严谨。核心域不一定是物流、医疗、金融等非计算机领域,也可以是计算机和软件领域。图2展示了不同系统的核心域和非核心域概念:


图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 用需求包来表达功能集合

当然,如果您硬要说,老子就喜欢叫"功能模块",那也可以,关键是要了解我上面说的道理。

术语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)。

术语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机的执行者储户"取款机应该怎么做你觉得最好",储户回答大实话"最好像我家抽屉一样拉开就拿,喏,把我家里的抽屉拿去做原型",需求人员显然不能把这个"抽屉"当真,只需要把"抽屉"背后的涉众利益提炼出来——储户希望操作次数尽可能少一些。最终系统的需求有多少尊重了这个利益,就要看储户在涉众排行榜上的排位了。

拿患者和医生类比也可以帮助理解。患者到医院对医生说"我腿疼,可能得了腿癌,我要做放疗",医生就给他做放疗?显然不是这样,医生只能把患者所说的一切当成素材,按照成熟的套路,该做什么检查就做什么检查,该如何治疗就如何治疗。

很多时候我们想涉众调研时,涉众直接给出解决方案——"我要一个像某某软件那样的!"如果你真的按照他说的做了,他用的时候又不满意了,而且他的其他同事更不满意。然后我们还委屈呢,都是按照当时开会时你说的做的,还有录音为证!

了解到"涉众无资格提供需求,和涉众交流的内容应该聚焦于涉众利益",可以帮助我们少犯错误。!

术语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 可选和推荐的建模元素用法(●表示优先使用,√表示可以使用 )

本文的pdf文件排版更佳,图片更清晰。请在http://www.umlchina.com/book/ctoterm.pdf下载。

[UMLChina,转载请注明出处。]