首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >CTO也糊涂的常用术语(01-02)20180514更新

CTO也糊涂的常用术语(01-02)20180514更新

作者头像
用户6288414
发布2019-09-23 14:30:54
3240
发布2019-09-23 14:30:54
举报
文章被收录于专栏:软件方法软件方法

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

到底含糊在哪里,错误在哪里,不仅仅是新手软件开发人员糊涂,许多入行多年的老手也一样。虽然很多老手功成名就,挂着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 用需求包来表达功能集合

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

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

图11 维基百科上关于业务架构的描述

我们再来看一些公司招聘“业务架构师”(Business Architect)的描述:

(待续)

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-05-14,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 UMLChina 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档