好书推荐:《大象:Thinking in UML》,软件设计的九阳真经

Posted PM杨堃

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了好书推荐:《大象:Thinking in UML》,软件设计的九阳真经相关的知识,希望对你有一定的参考价值。

书名:《大象:Thinking in UML(第2版)》

出版时间:2012年3月

豆瓣评分(截止202010):8.2

适合工作经验年限:5到10年

阅读难度:★★★★★

推荐指数:★★★

一句话简介:本书探讨了软件工程最本质且形而上的设计思维,全书约40%的内容可以让资深产品设计人员对软件设计产生更深刻、更本质的思考和认知,剩下60%的内容偏技术。此书具有一定阅读难度,至少需要5年以上工作经验,推荐希望提升内力的资深专家阅读。



在我印象中,凡是以“Thinking in”起名的书籍,都是大师级别作品。十几年前学习编程时,阅读了Bruce Eckel的《Thinking in Java》(中文译作Java编程思想,第四版豆瓣评分9.1,评论数3860),当时天天捧着800多页的天书《Thinking in Java》,真的是叹为观止,以为自己偷学了Java编程的葵花宝典。

 

当我第一次拿到《大象:Thinking in UML》纸质书时,不禁略皱眉头,这本同样砖头厚(526页)的大部头,真的也敢起名叫做Thinking in xxx?

 

但是阅读完全书后,确实不由深深佩服,中文书籍市场,能有这样一本软件工程领域的九阳真经,真是行业一大幸事。

 

引用作者原话,“《大象》是一本结合了面向对象方法、软件工程方法、基于 UML 的建模方法的全程建模的书”,其核心是通过对UML的讲述,抽丝剥茧的带读者体会了基于RUP(Rational Unified Process,统一过程,一种经典的重模式的软件工程实践理论)的软件设计构建理论框架。全书第一部分探讨的是UML设计元素的细节,产品经理可以泽清粗读,第二部分探讨了从需求采集、需求分析、系统分析到系统设计、开发上线全过程的软件工程实践。

 

在阅读中,读者将感受到软件建模、抽象的本质和核心要点,如果你有一定设计经验,书中讲述的很多内容将会和你的实践经验形成映射,激荡出你的思考和感悟。

 

RUP是一种很重的模式,虽然现代实践中已经很少严格遵循或采用,但是其中瀑布式的流程并不能简单地否定。比如说作者通过一个有趣的例子,生动的阐述了瀑布模式和XP模式(极限编程,敏捷中的一种)在实际应用中的对比。

 

你能想象洛克希德·马丁公司用XP的方法来开发F-35战斗机会是一个什么情形吗?没有人清楚地知道将来飞机的整体是什么样,好不容易设计出机翼来,另一个小组说我们决定改变一下气动外形,你们再重构一下吧;没有人知道最后飞机的性能怎么样,反正先造一架出来,要是摔了找找原因,改进改进,重构一下,再造一架……再摔了,没关系,咱们拥抱变更,再造就是了……

 

显然对这种大型产品来说XP方法是不可接受的,而RUP的稳步推进的方法却正好适合。那XP什么情况下适用呢?如果你是一个杂货店的老板,刚开业不知道什么样的商品受欢迎,没关系,先各进一小批货,卖上一段时间,受欢迎的货品多进,不受欢迎的不进,随时向顾客做一些调查,顾客喜欢什么商品就进什么,不断改进,最后一定会顾客盈门的。这时如果这个老板采用统一过程的方法,先做商业分析、客户关系分析、消费曲线分析……还没开业呢,估计就破产了,或者好不容易做出了一个商业策略,客户兴趣已经改变了。


外,RUP和XP也不是非此即彼的关系,比如在造F-35的过程中,对整体飞机来说,用RUP是适合的,具体到零部件倒是大可XP一把,先在风洞里试验试验,不符合条件就更换了再试,最终只要得到最适合的零部件就OK了。

 

作者的这个例子我觉得非常贴切的描述了B端产品和C端产品设计上的区别。研发B端产品很多时候更像是研发大型飞机,而非快速迭代的杂货店;但C端的很多业务和APP,确实像一个杂货店,需要快速迭代试错。

 

大家都知道我是非常推崇业务抽象建模、实体建模工作的,针对实体建模,作者也用了大量篇幅表达了自己的看法,这些观点都和我长期以来的想法不谋而合。在谈到业务场景用例和实体建模的关系式,作者提到:

 

如果说业务用例场景下的业务对象模型研究的是特定的业务实例(即业务对象结构如何实现该业务),那么领域模型研究的则是高于特定业务场景的一般规律(即试图定义出能够满足所有业务用例场景的对象结构)。可以说,领域模型是从所有业务用例场景对象交互模型当中抽象出来的更高级别的业务对象模型;它表示了业务对象结构和交互的一般规律,揭示了业务运行的“本质”和“核心”。

 

作者所说的领域模型,实际上和实体建模,在本质上是一回事,都是对现实世界客观事物的抽象提炼。实体建模是一个非常艰难的工作,在复杂业务领域,很多实体建模、领域模型都已经有了非常好的提炼,这是需要花时间学习的。作者进一步谈到:

 

在实际工作中,要建立好的领域模型是很困难的,我们必须对整个业务领域了解得非常非常透彻才有可能建立起很好的领域模型。这要求建模者具有深厚的行业知识背景,或者具备高超的抽象能力,并且遍历了绝大部分的业务用例场景。这不是一蹴而就的事。但是,一旦真正建立了全业务领域的领域模型,该软件产品也就脱离了依据特定项目定制开发的框框而进入了产品化。该公司也必然是该领域的行业带头人,卖的首先是业务咨询与服务,同时配套相关的支持软件。

 

在软件设计领域,有几种设计流派,例如用例驱动的设计(UDD,Use Case Driven Design),领域驱动的设计(DDD,Domain Drive Design),特性驱动的设计(FDD,Feature Driven Design)。目前用的比较多的,实际上依然是UDD。(虽然很多互联网的产品设计人员喜欢讲场景驱动的设计,或者通过User Story来拆解设计,但在业务产品设计领域,这些思路本质上都是相同的)

 

在《决胜B端》其中讲到产品细节方案设计一章,我们是以一个ER建模来开始的场景设计,其实有点类似于DDD的意思,但实际上,设计的起点并不一定都是建模,很多时候可能是场景梳理,在场景、流程构建之中,完成了实体的抽象和设计(DDD)。所以,UDD和DDD其实并没有绝对的谁先谁后问题,针对UDD和DDD,作者做了精彩的评价:

 

尽管从概念上来说,用例驱动方法和领域驱动方法里都提到了领域模型,但用例驱动方法中的领域模型是从属地位的,它是由用例推导(驱动)而产生的;而领域驱动方法里的领域模型则是核心,其它的一切都由它为基础来推导(驱动)。

 

如果纯从模型的价值上讲,领域驱动所建立的模型价值要比用例模型大得多。领域驱动体现了本质,而用例模型仅描述了表象,前者比后者更接近真理。一旦有机会能够建立起真正的领域模型,其价值之大是难以估量的。它表示你已经脱离了业务定制,脱离了满足当前需求,你已经理解并真正掌握了业务领域的原理,站在了行业领导者的位置。就如同你建立了牛顿三大定律一样,世间的万事万物都逃不出你的掌握。


在管理软件领域,经典的业务运作模式已经有了高度的总结提炼,背后对应着的软件设计的领域模型也有了非常准确的定义。类似于Oracle、Sap这些大型商业软件,之所以能够保持强大的灵活性,其本质上正是因为底层模型,即领域模型,即实体建模的抽象,已经非常灵活的能支持各种业务场景和情况,在这种强大的灵活底层依托之下,再加上强大的配置功能和一定程度的集成开发支持,才能做到可以经过简单定制实施,就适用于各种类型的客户。

 

所以一套商业软件产品,是否真正具备灵活性,并不是依赖其配置功能,而是取决于其底层模型。

真正具备这样深厚行业业务背景的通常都是那些在IT业历经多年的老牌软件厂商,如IBM、Oracle、SAP;或者著名的咨询公司,如埃森哲、德勤等。即便如这些做了几十年的厂商,要提炼出一个业务架构来也是相当不容易的。但也因此这些厂商是行业的领跑者,他们不仅仅实现客户的当前业务,他们还引导客户发展业务。而广大成长中的中小软件厂商,几乎不可能具备这样的行业深度和广度,并且在中国,客户方也极少会深度参与到项目当中,也就是说许多项目组里没有真正的领域专家。而没有领域专家的领域建模只能是一个笑话。

 

作者还讨论了关于软件设计,究竟是做项目,还是做产品的思考。有很多年轻的产品经理,在这个问题上总是感到困惑,面对客户海量的客户化定制需求,不知该如何处理。一方面,离散的客户定制化需求,首先要确定目标客户群体;但另一方面,也要思考软件产品以及产研团队,是否已经深入理解了业务背后的领域问题。作者谈到:

 

第一,如果你们的实力还不足以摆脱以项目为中心的运营模式,那么在实际项目中应当采用用例驱动方法而不是领域驱动方法。应当采用现实主义的做法,例如本书中所采用的领域建模方法(详见9.5节),在开发过程当中,仅针对某几个重要的问题领域来建立领域模型,寻求某个常见问题的通用解决方案而不是寻求整体业务架构。例如,权限问题领域、操作日志问题领域、业务档案问题领域等眼前的问题。


第二,如果你们暂时还无法达到这样的行业深度,而又想往行业领导者发展,那么你们应当建立研发中心,把实施项目与研发产品分离出来。实施项目负责积累业务知识,而产品研发负责把业务知识转化为领域模型和相应的产品。实施项目采用用例驱动方法以保证项目的交付,而研发中心则不断积累业务知识,逐步建立领域模型,把积累转化为业务模块,再把业务模块应用到实施项目中去检验和完善。

 

第三,如果你们已经在某个行业做了很多年,积累了相当深厚的业务知识背景;或者你们的确能够找到资深的业务专家,那么你们真是非常幸运,可以立即开始学习并建立领域模型,甚至可以直接采用领域驱动的方法实施项目。

 

以上是我挑选了一些书中印象比较深刻的内容,这本书虽然标题是UML,但实际上更多的讲述的是软件设计的本质。如果你有兴趣,可以挑选感兴趣的部分阅读。本书网上有电子版,微信读书也可以阅读。


对了,针对UML的学习,我之前专门制作了一期公开课,您可以购买知识星球免费学习所有公开课,也可以在千聊单独购买课程(39元)。



  推荐阅读:


以上是关于好书推荐:《大象:Thinking in UML》,软件设计的九阳真经的主要内容,如果未能解决你的问题,请参考以下文章

大象——Thinking in UML

大象——Thinking in UML

《大象 Thinking in UML》学习笔记——为什么需要UML?

01:关于《大象:Thinking UML》

Thinking in UML 学习笔记——建立对象模型

Thinking in UML 学习笔记——UML核心视图之类图