CTO也糊塗的常用術語:功能模組、業務架構、使用者需求、文件……

the7主題發表於2021-01-27

功能模組、業務架構、需求分析、使用者需求、系統分析、功能設計、詳細設計、文件、業務、技術……很多被隨口使用的名詞,其實是含糊甚至錯誤的。

到底含糊在哪裡,錯誤在哪裡,不僅僅是新手軟體開發人員糊塗,許多入行多年的老手也一樣。雖然很多老手功成名就,掛著CTO、總架構師等研發線的最高頭銜,但是心裡對這些概念也是一團漿糊。

可能有的人會說,不會吧,這些牛人帶團隊做出了讓公司賺錢的系統,怎麼會不清楚呢,只不過表達出來和你的表達不同而已吧?我只能很誠懇地再說一遍:很多“牛人”真的不清楚。當然,搞不清楚不妨礙做出賺錢的系統,就像有的人不瞭解人體執行機制憑感覺也活到了一百歲。您也可以說“做出過賺錢的系統就行了唄,管他清楚不清楚呢!”,對對對,您說的都對,但不清楚也還是不清楚。

我先說一下我在《軟體方法》一書中對軟體建模工作流的劃分:

軟體開發的一個迭代週期中需要思考四個問題,即四個工作流:

A-業務建模——定位需要改進的目標組織(人群或機構)以及該組織接下來最需要改進的問題。

B-需求——描述為了改進組織的問題,所引入的資訊系統必須具有的表現。

C-分析——提煉為了滿足功能需求,所引入的資訊系統需要封裝的核心域機制。

D-設計——考慮質量需求和設計約束,將核心域機制對映到選定非核心域上實現。

如圖1。

工作流

圖1 四個工作流

以上四個工作流的名稱使用了傳統術語,也有一定的模糊性(特別是業務建模)。更貼切的名稱是組織建模、需求建模、核心域建模、實現。如果您覺得業務建模、需求、分析、設計不好,直呼ABCD或改成阿豬、阿狗、阿雞、阿鴨也無所謂。

針對這些工作流的思考,其實就是建模。任何一個軟體專案,這些思考都是逃不掉的,也就是說,我們一直在建模,只不過很多人習慣於無意識地做,運氣時好時壞,速度時快時慢,有的人能夠有意識地做,讓汗水不白流。

思考的結果,可以用口頭表達,也可以用文字、其他表示法或自造符號來表達。用UML來表達,目前是一種不壞的做法。如果用UML表達,推薦的用法如圖2。可以看到,工作流D可以不需要用UML表達。

 

工作流

圖2 各工作流思考內容和推薦表達

再說一下核心域和非核心域的概念。一個軟體系統封裝了若干領域的知識,其中一個領域的知識代表了系統的核心競爭力,是系統和其他系統區分的關鍵所在。這個領域稱為"核心域",其他領域稱為"非核心域"。更通俗的說法是"業務"和"技術",但使用"核心域"和"非核心域"更嚴謹。核心域不一定是物流、醫療、金融等非計算機領域,也可以是計算機和軟體領域。圖3展示了不同系統的核心域和非核心域概念:

coredomainexample.png

圖3 不同系統的核心域、非核心域概念

好,根據以上的知識,我們來逐一剖析這些術語,可能有好幾十個。

術語01:功能模組

評價:“功能”屬於模糊術語,“模組”屬於模糊術語,“功能模組”屬於錯誤術語。

功能(Function)。當我們說起這個詞的時候,研究物件一般是系統。對於組織,一般說“組織的服務”,對於類,一般說“類的操作”。所以,“功能”屬於“B-需求”的範疇(功能需求),描述系統作為一個整體為其他系統提供的服務,把其他系統給它的輸入變成其他系統所需要的輸出。

但是,“功能需求”仍然不夠精確。例如,以自助櫃員機(ATM)為研究物件,“取現金”是“功能”,“登入”也是功能,“計算手續費”也是“功能”,到底“功能”有多大?用例的術語要嚴謹得多。“取現金”是一個用例,“登入”是用例中的一個回合,“計算手續費”是一個步驟。

模組(Module)。當我們說起這個詞的時候,研究物件一般是系統。模組表示系統的組成部分,屬於“C-分析”和“D-設計”的範疇。這個詞也是模糊的。這個模組是一個控制元件?一個類?若干個類形成的元件?

如果說“功能”和“模組”是模糊的,那麼“功能模組”就是錯誤的,這個詞混淆了系統外部和內部的區別,需求和設計的區別。

“功能”是系統作為一個整體所需要完成的行為,“模組”是系統的內部結構。連起來說“功能模組”,意味著在意識裡認為“功能”和“模組”有直接的對映關係,甚至認為“模組”是屬於某個“功能”的模組,是為了完成某個“功能”而存在的。

這樣的認識是錯誤的。如圖4所示,完成某個“功能”需要若干“模組”的協作,而某個“模組”也會參與完成若干“功能”,例如可以看出“模組6”被反覆使用了很多次。如果將“功能”和“模組”直接對映,系統內部將出現大量冗餘。

cto04.png

圖4 “功能”和“模組”的對映是多對多的

人體就是一個系統,基本功能有走路、跳躍、吃飯等,但是設計人體結構時,不能從外部直接對映到內部,得到人體由“走路模組”、“跳躍模組”、“吃飯模組”組成。人體的“模組”是五官四肢和內臟,還有最關鍵的——“大腦”。不管是走路、跳躍還是吃飯或者將來發展出更多的“功能”,都由這些“模組”協作完成。

那麼,那些經常被稱為“功能模組”的東西,應該怎麼稱呼合適呢?圖5是百度“功能模組”得到的排第一位的圖片:

cto05.png

圖5 百度“功能模組”得到的排第一位的圖片,來自 http://www.think58.com/asp/9182.html ,非UML圖

從圖5得知,“商品銷售管理系統”有很多功能,其中一部分是給使用者使用的,另一部分是給管理員使用的,所以很多人會說“本系統分為兩大功能模組——使用者模組和管理員模組”,但是這樣的說法在意識裡不知不覺犯了從外直接對映內部的錯誤,如圖6。

cto06.png

圖6 不知不覺從外部對映到內部

還是用人舉例。人有很多功能,有些是為老闆提供的,有些是為老婆提供的,還有些是為老爸老媽提供的。按照圖5的意思,人可以切割成“老闆模組”、“老婆模組”……人體確實可以根據內部的耦合和內聚情況切割成不同層次的“模組”(細胞→組織→器官→子系統),但是和外面的切割沒有直接的對映關係。為老闆服務也好,為老婆服務也好,沒有強大的血液迴圈子系統(心臟、血管)和神經系統(腦、脊髓、各種神經)都是搞不定的。

設想食人族把一個人大卸八塊(對,模組的塊),分贓時會怎麼說?“來,左腿歸你,下水歸我”,還是“走路功能歸你,吃飯功能歸我”?

如果要描述若干功能的集合,更貼切的術語應該是“功能包”,如圖7所示。

cto07.png

圖7 用需求包來表達功能集合

當然,如果您硬要說,老子就喜歡叫“功能模組”,那也可以,關鍵是要了解我上面說的道理。

術語02:業務架構

評價:“業務”屬於模糊術語,“架構”屬於模糊術語,“業務架構”屬於模糊術語。

業務(Business)。“業務”這個詞在軟體開發團隊中使用得很頻繁,例如“我是一名業務架構師”、“我們要了解業務”等等,但是往往說話的人未必真的理解話中的“業務”具體指什麼。

有時候“業務”指的是內容上的劃分,含義是“核心域”。

例如,一個餐館系統,訂單和菜品的關係屬於“業務知識”,折扣的計算規則屬於“業務規則”,如圖8所示。

cto08.png

圖8 餐館系統需要封裝的“業務”——核心域類圖

此時,和“業務”相對應的就是“技術”了。開發人員假裝謙虛“我是做技術的,業務不太懂唉”,就是這個意思。甚至有的開發人員在潛意識裡是這樣劃分的:

我懂且我感興趣的知識→技術;(我是一名Java程式設計師,Java編碼是技術)

我懂但不感興趣的知識→業務;(下單、收銀、配送我懂一些,但不感興趣,這些是業務)

我不懂但感興趣的知識→高科技;(我不懂深度學習,但很感興趣,哇塞,高科技)

我不懂且不感興趣的東東→忽悠。(我不懂UML建模,也不感興趣,媽的,忽悠)

有時候“業務”指的是範圍上的劃分,含義是“組織級別”。例如,“業務建模”說的是組織級別的建模、“業務用例”說的是組織為其他組織提供的服務,“業務流程”說的是組織內各個系統之間協作的流程。如圖9,表達了餐館的“業務流程”。

cto09.png

圖9 餐館組織的“業務”流程

此時,和“業務”相對應的就是“系統”了。

架構(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."

軟體業樂於做這樣的事——找一些詞彙,並引申出大量微妙而又互相矛盾的含義。一個最大的受害者就是“架構”。

維基百科中這樣描述“架構”:

軟體架構是一個系統的草圖。軟體架構描述的物件是直接構成系統的抽象元件。各個元件之間的連線則明確和相對細緻地描述元件之間的通訊。在實現階段,這些抽象元件被細化為實際的元件,比如具體某個類或者物件。

我的歸納:架構是多個系統內部共有的抽象機制。

要點一:內部。系統提供的各種功能,不屬於“架構”。要點二:共有。架構是一種複用機制。它獨立於單個系統,圍繞它可以組裝成系統的家族。

圖10是現在常提到的一個架構。可以斷定,我們會在很多軟體系統中發現這樣的機制。圖10表達的是不同領域(UI、Database、核心域……)之間互動的機制。不管系統的核心域是哪一個(保險、物流、醫療),這樣的機制都可以存在。

cto10.png

圖10 域之間的架構,來自taimila.com,非UML圖

圖11也是架構,也可以在千萬個軟體系統中發現這樣的機制。相對於圖10,圖11表達的是某個領域內部各種領域概念的關係。不管將核心域概念對映到哪些非核心域上(Android還是iOS,Vue還是React)得到系統,這樣的機制都可以存在。

cto11.png

cto112.png

圖11 域內部的架構

這裡再囉嗦幾句。在一些軟體開發大會常可以看到這樣的場景:某電子商務網站的架構師上臺講了一通,接著某視訊網站的架構師上臺也講了一通,咦,兩個演講內容如此相似?原來,他們講的都是自己系統中各域之間的機制(類似圖 10),而不是核心域內部的機制(類似圖 11)。究其原因也許並非不為,而是不能——開發人員對自己所開發系統的核心域研究太淺。許多“網紅程式設計師 ”在網上談論的內容大多是某種語言或框架的新特性,少有探討他當前所開發系統的複雜領域邏輯,也是同樣的原因:並非不為,而是不能。

業務架構。根據以上講述,這個詞有兩種含義。

含義一:組織的內部機制。此時,“業務”作“組織”解。圖9就描述了這樣的機制。維基百科採用的就是這種含義,如圖12。此時業務架構師應該負責的是“A-業務建模”的工作。

cto12.png

圖12 維基百科上關於業務架構的描述

我們再來看一些公司招聘“業務架構師”(Business Architect)的描述,有的崗位要求還比較貼近“A-業務建模”,如圖13。

cto13.png

 

圖13 業務架構師崗位描述1,來自拉勾網

也有不知所云的崗位要求,如圖14。

cto14.png

圖14 業務架構師崗位描述2,來自拉勾網

含義二:系統內部的核心域機制。此時,“業務”作“核心域”解。圖11就描述了這樣的機制。此時業務架構師應該負責的是“C-分析”的工作。

遺憾的是,在招聘網站上搜不到符合這個含義的“業務架構師”崗位。搜“架構師”可發現其崗位要求覆蓋了“C-分析”和“D-設計”。上文已經說過,絕大多數的“架構師”熟悉的是“D-設計”的工作(圖10),不擅長“C-分析”的工作(圖11)。

術語03:使用者需求

評價:“使用者”屬於模糊術語,“需求”屬於明確術語,“使用者需求”屬於錯誤術語。

使用者(User)。首先,使用者預設是人,沒有稱某個軟體系統為使用者的——“本系統的另一個使用者是第三方支付系統”;其次使用者是和所研究系統有互動的人。例如,我正在用Word寫這篇文章,我是Word的使用者。以上是最常見的理解。

有時“使用者”也會用在根本沒有人機互動的地方,如圖15。一個定時收集資訊的系統,根本不需要和人互動,但需求人員也會說“使用者是怎麼要求的?多長時間收集一次?速度要多快?源格式和目標格式是怎樣的?”此時,“使用者”不是指和所研究系統互動的人,而是系統所服務的目標組織的某個負責和開發團隊介面的人。例如,假設這個系統為某市國稅局服務的,需求人員剛才說的“使用者”可能是國稅局資訊中心的副主任。怎樣稱呼這位副主任才正確,後文再說。

cto15.png

圖15 無人蔘與互動的收集過程

“使用者”一詞存在的問題:

(1)很多時候我們口中的“使用者”是隨意推測的。

我們來看圖9的餐館的例子。我們把它搬到圖16。假設圖16是餐館的現狀,餐館的老闆希望在此現狀之上進一步改進。需求人員很容易先入為主,認定上面的人就是新系統的“使用者”,然後逐個找這些“使用者”調研。

cto16.png

圖16 餐館的現狀

這樣的先入為主是不對的。也許餐館老闆希望看到的改進如圖17所示。從圖中可以看到,領位員這個崗位都不需要了,還找他調研個啥。如果連服務員都可以不要,老闆可能覺得更爽。

cto17.png

圖17 對餐館的一種改進

(2)“使用者”混淆了演員和觀眾。

我們先來看用例(Use Case)的一些概念。如圖18所示,用例把軟體系統看作一部電影,演員(Actor,執行者)在臺上表演,觀眾(Stakeholder,涉眾)在臺下看,觀眾按照他們的地位排排坐。演員在臺上表演什麼是由觀眾的口味決定的,先照顧前排的觀眾,如果有餘力,再照顧後排的觀眾。

cto18.png

圖18 演員(執行者,Actor)在臺上表演,觀眾(涉眾,Stakeholder)在臺下看

用例使用“執行者”(Actor)和“涉眾”(Stakeholder)代替了原來的“使用者”,這是一個非常大的突破。“使用者”這個詞混淆了演員和觀眾的區別。過去經常說“找使用者調研需求”,這是錯誤的。所謂“使用者”,就是上臺表演的人類演員。找使用者調研,相當於找演員問劇本應該是什麼內容,豈不是很荒謬?劇本應該由編劇向觀眾調研編寫出來,然後由各路演員在臺上演繹。

演員如果是人類,那麼在觀眾席上也會有一個位置,不過在第幾排就不知道了。范冰冰這樣的大咖,可能有能力影響劇本的內容,跑龍套的就算了吧。

在臺上當“使用者”當得越歡的涉眾,往往在涉眾排行榜上排位越靠後。您想想,整天操作電腦搞得手僵脖子硬的“使用者”,有幾個是職位高的呢?真正位高權重的涉眾,雖然偶爾也會上臺表演,但更多時候是坐在臺下看戲。建模人員如果過多地關注“使用者”,花在重要的前排涉眾身上的時間可能就不夠了。

像“使用者故事”這樣的方法在開發一些面向大眾的網際網路系統時還能應付,因為這類系統的執行者往往屬於前排涉眾,以上問題就被掩蓋了。如果開發涉眾較多、利益衝突微妙的系統,應該採用用例這樣更嚴謹的需求技能。例如做一個手機遊戲,重點調研玩家這個“使用者”是可以的,做一個某單位的櫃檯系統,也重點調研視窗工作人員(希望幹活越少越好),那背後的領導和其他同事就遭殃了。

另外,現在的系統做出來,越來越多的介面不是面向人類的,而是面向另一個軟體系統,也就是說沒有“使用者”。兩個電腦系統互動的需求,難道就不用做了,或者可以隨便做?非也。那只是相當於上臺表演的不是人,是功夫熊貓、變形金剛和喜羊羊灰太狼,但是臺下對錶演說好說壞的觀眾依然是人。建立“執行者和系統在臺上表演,涉眾在臺下看錶演”的概念,在執行者為非人系統時對捕獲需求很有幫助。

(3)“使用者”是拒絕深入思考的遮羞布。

即使是演員和前排觀眾重疊的系統,“使用者”也是一個阻攔需求人員深入思考的詞彙。許多產品經理把“使用者”掛在嘴邊,“要從使用者的角度思考”,“使用者滿意的才是好產品”等等,甚至還有“賈伯斯不在意使用者的意見”等奇談怪論。問題來了,誰是使用者?

一個老頭找到PS可樂公司,告訴他們的主管,“我可是你們的忠誠客戶啊!我喝過的可樂罐排成線,可以從蘋果園排到通州(北京從西到東)。現在我老了,我對你們的可樂下一個版本提出如下要求:第一,我有胃病,下一個版本不要有這麼多氣;第二,我有糖尿病,下一個版本里面不要有糖。”PS可樂公司的主管很感動,哇,這麼棒的顧客,把要求提得那麼具體,省下好多我們調研需求的時間,好,下個版本就這麼辦!

可惜,現實生活中不會有這樣的場景。老頭老太太可以買可樂喝,甚至可以買給自己的寵物喝,PS可樂公司不會攔著。問題在於,老頭老太太提的要求,或者為他們的寵物提的要求(注意用詞:是要求,不是需求),PS可樂公司不會放在重要的位置來考慮,因為PS可樂的目標人群是青少年。可惜,很多時候我問需求人員:“可樂賣給誰?”得到的回答大多是“賣給消費者”,“賣給想喝可樂的人”等對做出好賣的可樂沒有幫助的、正確而無用的廢話。

我在《軟體方法》中,用“老大”取代了“使用者”。“老大”是一個真實存在的具體的人。定位“老大”的具體方法參見《軟體方法》第2章,和Persona方法類似。但是Persona是虛構一個“使用者畫像”,說白了也是鼓勵需求人員逃避深入第一線調研的辛苦,安心閉門造車。例如,為女性做一個產品,建模人員深入第一線調研,面對的調研物件是一個個具體的女性。如果建模人員把調研的精力花在羅玉鳳身上,留給林志玲的精力就不多了,所以必須思考羅玉鳳更像老大還是林志玲更像老大的問題。相比起來,關在辦公室隨意捏造一個符合自己要求的“女性”省事多了。如果滿足於Persona,歸根結底還是在內心裡沒有認識到深入第一線調研的重要性。

“老大”的頭腦是一塊塊的戰場,所研發的系統是一支軍隊。研發團隊的領導是軍隊指揮官,他負責找到自己的軍隊最值得投入的戰場,指揮軍隊和敵人廝殺,佔領戰場,或者防守住敵人的進攻。戰局是殘酷的。您手上的三萬紅軍下一步應該殺向哪裡,可選項其實少之又少,您必須竭盡全力把這個戰場找出來。可惜,許多人低估了現實的殘酷,意淫自己手裡有百萬大軍,愛殺往哪裡就殺往哪裡。

cto19.png

圖19 和對手在老大的大腦裡廝殺

需求(Requirement)。明確術語,不再單獨闡述。

使用者需求。錯誤術語。需求指系統對外提供的功能效能,如果要在“需求”前面加一個定語,這個定語是“系統”——“系統的需求”。

系統的需求就像電影的劇本,規定了電影拍出來必須滿足的內容,它是平衡了各種觀眾的口味(先照顧第一排觀眾,再照顧第二排……)得到的結果。對所有觀眾、演員來說,劇本就在那裡,不會因為某個觀眾不喜歡其中某個情節而變化,也不會因為暫時還沒有找到演員來拍成電影而變化。所以,不存在什麼“使用者需求”、“設計需求”、“架構需求”、“開發需求”、“編碼需求”等東西。需求不是你的、我的、他的,是系統的,是你我他最終達成的關於系統的一份契約。

那麼,“使用者”後面能跟什麼呢?可以跟“要求”。更嚴謹的術語是“涉眾利益”。需求像電影劇本,涉眾像電影觀眾。劇本只有一份,觀眾卻是多種多樣,不同觀眾的欣賞角度和口味不同。魯迅說過:一部紅樓夢,經學家看見《易》,道學家看見淫,才子看見纏綿,革命家看見排滿,流言家看見宮闈祕事。

軟體系統也是如此。例如一個生產執行管理系統,老大製造部王部長關注的是“縮短從接到市場部訂單到交付產品的時間週期”,車間工人更關心“我這個崗位的工作量會不會增加”,庫管員可能擔心“以後不好搞手腳”。系統的需求首先要照顧王部長的利益,在不損害王部長利益的前提下,還有餘力的話再照顧車間工人和庫管員。對於實在照顧不到的後排涉眾,很多時候只好抱歉了,這個系統可能會損害你的利益。

軟體的需求規約相當於電影劇本。電影劇本不是由觀眾直接提供,而是由編劇根據不同觀眾的口味編出來的。同樣,軟體需求不是由涉眾直接提供的,而是由需求人員綜合不同涉眾的利益來決定的。涉眾沒有資格提供需求。

系統的需求是平衡各種涉眾利益得到的,不由單一涉眾決定。以ATM機為例,如果需求人員詢問ATM機的執行者儲戶“取款機應該怎麼做你覺得最好”,儲戶回答大實話“最好像我家抽屜一樣拉開就拿,喏,把我家裡的抽屜拿去做原型”,需求人員顯然不能把這個“抽屜”當真,只需要把“抽屜”背後的涉眾利益提煉出來——儲戶希望操作次數儘可能少一些。最終系統的需求有多少尊重了這個利益,就要看儲戶在涉眾排行榜上的排位了。

拿患者和醫生類比也可以幫助理解。患者到醫院對醫生說“我腿疼,可能得了腿癌,我要做放療”,醫生就給他做放療?顯然不是這樣,醫生只能把患者所說的一切當成素材,按照成熟的套路,該做什麼檢查就做什麼檢查,該如何治療就如何治療。

很多時候我們想涉眾調研時,涉眾直接給出解決方案——“我要一個像某某軟體那樣的!”如果你真的按照他說的做了,他用的時候又不滿意了,而且他的其他同事更不滿意。然後我們還委屈呢,都是按照當時開會時你說的做的,還有錄音為證!

瞭解到“涉眾無資格提供需求,和涉眾交流的內容應該聚焦於涉眾利益”,可以幫助我們少犯錯誤。

術語04:文件

評價:“文件”屬於模糊術語。

先列出使用“文件”的一些話語:

你們怎麼一上手就寫程式碼,連個文件都沒有!

你現在在做什麼?我在寫文件。

程式碼就是文件。

從以上話語可以看出以下問題:

(1)在許多軟體開發人員的大腦裡,“文件”的意思就是“程式碼之外的其他工件”。由於缺乏軟體工程方面的基本知識,對之前提到的“A-業務建模”、“B-需求”、“C-分析”、“D-設計”等工作流沒有概念,只好把軟體開發工作分為“寫程式碼”和“寫文件”兩部分。(其實,就連什麼叫“程式碼”,很多人也是糊塗的,這一點後面再說。)

(2)軟體開發人員一旦把工件簡單分割為“程式碼”和“文件”,還會導致這樣的誤解:認為“文件”只不過是“程式碼”的一種比較概要或比較形象的表現形式,不同的“文件”代表著“程式碼”的不同檢視,可以讓開發人員從不同的視角觀察程式碼,這樣就便於人腦把握程式碼的複雜性。如圖20所示。

cto20.png

圖20 誤解:文件只是程式碼的檢視

這種誤解不只“普通”的開發人員會有。Martin Fowler所著的UML暢銷書《UML精粹》,認為UML有三種用法:草稿、藍圖和程式語言,也是僅從編碼的角度來說的。從Fowler寫作的其他書籍《重構》、《企業應用架構模式》、《分析模式》等可以知道,他的研究工作集中在分析設計工作流,在業務建模和需求方面研究不多。

這樣的誤解就會導致推論:只要“程式碼”寫得自己“會說話”,那麼“程式碼就是文件”,“文件”就不需要了。本來“文件”就是“程式碼以外的其他東西”,這麼一推,就變成了“程式碼就是一切”。

(3)把“文件”當作“程式碼”的檢視還會帶來下面這種思維顛倒:先拍腦袋實現,然後再從實現反推其他工作流的內容。例如下面的對話:

張三:這個不應該是系統的用例(如果您不理解什麼叫“用例”,就先把它理解為“功能”好了)。

李四:是的!我都寫好了,執行一下給你看,這個系統確實提供了這個用例。

是否系統的用例應該以“好賣”來判斷。權衡涉眾利益之後覺得應該有,系統就有,不該有就沒有,而不是我寫好了程式碼,所以就應該有。

張三:這兩個類關係不應該是泛化,而是關聯。

李四:是泛化,不信我開啟程式碼給你看,或者逆向工程轉出類圖給你看。

是否泛化關係應該以“符合領域內涵”來判斷,而不是先寫好程式碼“人是豬的一種”(肯定編譯通過),再用寫好的程式碼來證明“人是豬的一種”。

(4)“文件”還意味著它和“程式碼”使用的可能是不同的工具寫出來的。在Visual Studio、Eclipse裡面寫出來的叫“程式碼”,在Word、wiki、Visio、EA等等裡面寫或者畫出來的叫“文件”。

正確的理解是:

不同工作流產出的工件之間的區別不在於形式,而在於思考和表達的內容,如圖21所示。

cto21.png

圖21 建模工作流思考內容

如果清楚瞭解“區別在於內容”這一點,就知道“我在寫文件”這樣的話只是表達“我正在用文件編輯工具在工作”,沒有其他意義。你在寫什麼文件?“業務建模”?“需求”?“分析”?“設計”?我不寫,我畫圖難道不可以嗎?我不寫不畫,我用語音清楚地表達出組織的流程,不可以嗎?更有意義的說法應該是“我在做業務建模”。如果說“文件”二字可以給您帶來不可替代的快感,可以說“我在寫業務建模文件”。

內容和形式的組合是靈活的。很流行的“程式碼就是設計”這句話的意思就是,設計工作流目前推薦的做法是不需要畫UML圖或者寫“設計文件”,直接用原始碼來表達設計模型。編碼本身就是一種建模工作。計算機執行的是二進位制指令,原始碼實際上也是“模型”。之所以被稱為“原始碼”,是因為它是人腦需要編輯的最低形式模型(編輯完這個就好,後面的事情就可以交給計算機了!)。這個最低形式模型隨著時代的發展不斷變化。

如圖21所示,最初的原始碼是機器語言。程式設計師在紙帶或卡片上打孔來表達0和1。後來發現這樣太累了,於是發明了一些助記符,這就是組合語言。 今天會有開發人員故意裝×,“這些我不太懂唉,我是做底層的,用C編碼”,可是C語言卻被歸類為“高階語言”,因為類似C這樣的語言出現的時候, 大多數程式設計師編輯的是組合語言,C相對於彙編來說,當然很高階。今天的一名企業應用程式設計師,最終需要編輯的可能有 HTML、CSS、JavaScript、Java、配置指令碼、SQL等,這些就是現在的“原始碼”的形式。

cto22.png

圖22 “原始碼”的發展歷程

從圖22中的“歷史程式”來看,大趨勢是人腦要編輯的“原始碼”離計算機原來越遠,離領域越來越近。至於最終什麼樣的具體形式能成為下一形式的代表,只好看各種語言的“個人奮鬥”了。

同理,如果人腦只需要編輯UML模型就可以實現系統,那麼“模型就是原始碼”。例如用帶有設計級除錯和強大程式碼生成能力的工具IBM Rational Rhapsody開發實時嵌入系統,在配置好和IDE的整合之後,人腦只需要編輯和除錯UML模型(主要是類圖和狀態機圖),就可以實現系統,不需要在IDE裡敲字元。感興趣的讀者可以自己去看Rhapsody附帶的例子。

“程式碼就是設計”可以,那麼“程式碼就是需求”可以嗎?當然也可以。例如,把整個系統看作一個類,那麼這個類的操作就是系統的需求,因為它表達的是系統作為整體提供的服務。

我們在使用UML建模的時候,各種建模元素和建模內容也是靈活匹配的。例如,狀態機圖,可能一看到就想起分析設計,其實也可以用來表達需求。圖23把“電視”作為整體來畫狀態機,表達的就是“電視”的需求。

cto23.png

圖23 用狀態機圖表達電視的需求(讀者可以自行思考圖中?處應該寫什麼。看起來一目瞭然,其實寫對不容易。)

當然,不同的內容有推薦的形式。各建模工作流可以選用的建模圖形以及推薦用法如前文圖2所示。

相關文章