功能模組、業務架構、需求分析、使用者需求、系統分析、功能設計、詳細設計、文件、業務、技術……很多被隨口使用的名詞，其實是含糊甚至錯誤的。
到底含糊在哪裡，錯誤在哪裡，不僅僅是新手軟體開發人員糊塗，許多入行多年的老手也一樣。雖然很多老手功成名就，掛著CTO、總架構師等研發線的最高頭銜，但是心裡對這些概念也是一團漿糊。
可能有的人會說，不會吧，這些牛人帶團隊做出了讓公司賺錢的系統，怎麼會不清楚呢，只不過表達出來和你的表達不同而已吧？我只能很誠懇地再說一遍：很多“牛人”真的不清楚。當然，搞不清楚不妨礙做出賺錢的系統，就像有的人不瞭解人體執行機制憑感覺也活到了一百歲。您也可以說“做出過賺錢的系統就行了唄，管他清楚不清楚呢！”，對對對，您說的都對，但不清楚也還是不清楚。
我先說一下我在《軟體方法》一書中對軟體建模工作流的劃分：
軟體開發的一個迭代週期中需要思考四個問題，即四個工作流：
A-業務建模——定位需要改進的目標組織（人群或機構）以及該組織接下來最需要改進的問題。
B-需求——描述為了改進組織的問題，所引入的資訊系統必須具有的表現。
C-分析——提煉為了滿足功能需求，所引入的資訊系統需要封裝的核心域機制。
D-設計——考慮質量需求和設計約束，將核心域機制對映到選定非核心域上實現。
如圖1。
圖1 四個工作流
以上四個工作流的名稱使用了傳統術語，也有一定的模糊性（特別是業務建模）。更貼切的名稱是組織建模、需求建模、核心域建模、實現。如果您覺得業務建模、需求、分析、設計不好，直呼ABCD或改成阿豬、阿狗、阿雞、阿鴨也無所謂。
針對這些工作流的思考，其實就是建模。任何一個軟體專案，這些思考都是逃不掉的，也就是說，我們一直在建模，只不過很多人習慣於無意識地做，運氣時好時壞，速度時快時慢，有的人能夠有意識地做，讓汗水不白流。
思考的結果，可以用口頭表達，也可以用文字、其他表示法或自造符號來表達。用UML來表達，目前是一種不壞的做法。如果用UML表達，推薦的用法如圖2。可以看到，工作流D可以不需要用UML表達。
圖2 各工作流思考內容和推薦表達
再說一下核心域和非核心域的概念。一個軟體系統封裝了若干領域的知識，其中一個領域的知識代表了系統的核心競爭力，是系統和其他系統區分的關鍵所在。這個領域稱為"核心域"，其他領域稱為"非核心域"。更通俗的說法是"業務"和"技術"，但使用"核心域"和"非核心域"更嚴謹。核心域不一定是物流、醫療、金融等非計算機領域，也可以是計算機和軟體領域。圖3展示了不同系統的核心域和非核心域概念：
圖3 不同系統的核心域、非核心域概念
好，根據以上的知識，我們來逐一剖析這些術語，可能有好幾十個。
術語01：功能模組
評價：“功能”屬於模糊術語，“模組”屬於模糊術語，“功能模組”屬於錯誤術語。
功能（Function）。當我們說起這個詞的時候，研究物件一般是系統。對於組織，一般說“組織的服務”，對於類，一般說“類的操作”。所以，“功能”屬於“B-需求”的範疇（功能需求），描述系統作為一個整體為其他系統提供的服務，把其他系統給它的輸入變成其他系統所需要的輸出。
但是，“功能需求”仍然不夠精確。例如，以自助櫃員機（ATM）為研究物件，“取現金”是“功能”，“登入”也是功能，“計算手續費”也是“功能”，到底“功能”有多大？用例的術語要嚴謹得多。“取現金”是一個用例，“登入”是用例中的一個回合，“計算手續費”是一個步驟。
模組（Module）。當我們說起這個詞的時候，研究物件一般是系統。模組表示系統的組成部分，屬於“C-分析”和“D-設計”的範疇。這個詞也是模糊的。這個模組是一個控制元件？一個類？若干個類形成的元件？
如果說“功能”和“模組”是模糊的，那麼“功能模組”就是錯誤的，這個詞混淆了系統外部和內部的區別，需求和設計的區別。
“功能”是系統作為一個整體所需要完成的行為，“模組”是系統的內部結構。連起來說“功能模組”，意味著在意識裡認為“功能”和“模組”有直接的對映關係，甚至認為“模組”是屬於某個“功能”的模組，是為了完成某個“功能”而存在的。
這樣的認識是錯誤的。如圖4所示，完成某個“功能”需要若干“模組”的協作，而某個“模組”也會參與完成若干“功能”，例如可以看出“模組6”被反覆使用了很多次。如果將“功能”和“模組”直接對映，系統內部將出現大量冗餘。
圖4 “功能”和“模組”的對映是多對多的
人體就是一個系統，基本功能有走路、跳躍、吃飯等，但是設計人體結構時，不能從外部直接對映到內部，得到人體由“走路模組”、“跳躍模組”、“吃飯模組”組成。人體的“模組”是五官四肢和內臟，還有最關鍵的——“大腦”。不管是走路、跳躍還是吃飯或者將來發展出更多的“功能”，都由這些“模組”協作完成。
那麼，那些經常被稱為“功能模組”的東西，應該怎麼稱呼合適呢？圖5是百度“功能模組”得到的排第一位的圖片：
圖5 百度“功能模組”得到的排第一位的圖片，來自 http://www.think58.com/asp/9182.html ，非UML圖
從圖5得知，“商品銷售管理系統”有很多功能，其中一部分是給使用者使用的，另一部分是給管理員使用的，所以很多人會說“本系統分為兩大功能模組——使用者模組和管理員模組”，但是這樣的說法在意識裡不知不覺犯了從外直接對映內部的錯誤，如圖6。
圖6 不知不覺從外部對映到內部
還是用人舉例。人有很多功能，有些是為老闆提供的，有些是為老婆提供的，還有些是為老爸老媽提供的。按照圖5的意思，人可以切割成“老闆模組”、“老婆模組”……人體確實可以根據內部的耦合和內聚情況切割成不同層次的“模組”（細胞→組織→器官→子系統），但是和外面的切割沒有直接的對映關係。為老闆服務也好，為老婆服務也好，沒有強大的血液迴圈子系統（心臟、血管）和神經系統（腦、脊髓、各種神經）都是搞不定的。
設想食人族把一個人大卸八塊（對，模組的塊），分贓時會怎麼說？“來，左腿歸你，下水歸我”，還是“走路功能歸你，吃飯功能歸我”？
如果要描述若干功能的集合，更貼切的術語應該是“功能包”，如圖7所示。
圖7 用需求包來表達功能集合
當然，如果您硬要說，老子就喜歡叫“功能模組”，那也可以，關鍵是要了解我上面說的道理。
術語02：業務架構
評價：“業務”屬於模糊術語，“架構”屬於模糊術語，“業務架構”屬於模糊術語。
業務（Business）。“業務”這個詞在軟體開發團隊中使用得很頻繁，例如“我是一名業務架構師”、“我們要了解業務”等等，但是往往說話的人未必真的理解話中的“業務”具體指什麼。
有時候“業務”指的是內容上的劃分，含義是“核心域”。
例如，一個餐館系統，訂單和菜品的關係屬於“業務知識”，折扣的計算規則屬於“業務規則”，如圖8所示。
圖8 餐館系統需要封裝的“業務”——核心域類圖
此時，和“業務”相對應的就是“技術”了。開發人員假裝謙虛“我是做技術的，業務不太懂唉”，就是這個意思。甚至有的開發人員在潛意識裡是這樣劃分的：
我懂且我感興趣的知識→技術；（我是一名Java程式設計師，Java編碼是技術）
我懂但不感興趣的知識→業務；（下單、收銀、配送我懂一些，但不感興趣，這些是業務）
我不懂但感興趣的知識→高科技；（我不懂深度學習，但很感興趣，哇塞，高科技）
我不懂且不感興趣的東東→忽悠。（我不懂UML建模，也不感興趣，媽的，忽悠）
有時候“業務”指的是範圍上的劃分，含義是“組織級別”。例如，“業務建模”說的是組織級別的建模、“業務用例”說的是組織為其他組織提供的服務，“業務流程”說的是組織內各個系統之間協作的流程。如圖9，表達了餐館的“業務流程”。
圖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、核心域……）之間互動的機制。不管系統的核心域是哪一個（保險、物流、醫療），這樣的機制都可以存在。
圖10 域之間的架構，來自taimila.com，非UML圖
圖11也是架構，也可以在千萬個軟體系統中發現這樣的機制。相對於圖10，圖11表達的是某個領域內部各種領域概念的關係。不管將核心域概念對映到哪些非核心域上（Android還是iOS，Vue還是React）得到系統，這樣的機制都可以存在。
圖11 域內部的架構
這裡再囉嗦幾句。在一些軟體開發大會常可以看到這樣的場景：某電子商務網站的架構師上臺講了一通，接著某視訊網站的架構師上臺也講了一通，咦，兩個演講內容如此相似？原來，他們講的都是自己系統中各域之間的機制（類似圖 10），而不是核心域內部的機制（類似圖 11）。究其原因也許並非不為，而是不能——開發人員對自己所開發系統的核心域研究太淺。許多“網紅程式設計師 ”在網上談論的內容大多是某種語言或框架的新特性，少有探討他當前所開發系統的複雜領域邏輯，也是同樣的原因：並非不為，而是不能。
業務架構。根據以上講述，這個詞有兩種含義。
含義一：組織的內部機制。此時，“業務”作“組織”解。圖9就描述了這樣的機制。維基百科採用的就是這種含義，如圖12。此時業務架構師應該負責的是“A-業務建模”的工作。
圖12 維基百科上關於業務架構的描述
我們再來看一些公司招聘“業務架構師”（Business Architect）的描述，有的崗位要求還比較貼近“A-業務建模”，如圖13。
圖13 業務架構師崗位描述1，來自拉勾網
也有不知所云的崗位要求，如圖14。
圖14 業務架構師崗位描述2，來自拉勾網
含義二：系統內部的核心域機制。此時，“業務”作“核心域”解。圖11就描述了這樣的機制。此時業務架構師應該負責的是“C-分析”的工作。
遺憾的是，在招聘網站上搜不到符合這個含義的“業務架構師”崗位。搜“架構師”可發現其崗位要求覆蓋了“C-分析”和“D-設計”。上文已經說過，絕大多數的“架構師”熟悉的是“D-設計”的工作（圖10），不擅長“C-分析”的工作（圖11）。
術語03：使用者需求
評價：“使用者”屬於模糊術語，“需求”屬於明確術語，“使用者需求”屬於錯誤術語。
使用者（User）。首先，使用者預設是人，沒有稱某個軟體系統為使用者的——“本系統的另一個使用者是第三方支付系統”；其次使用者是和所研究系統有互動的人。例如，我正在用Word寫這篇文章，我是Word的使用者。以上是最常見的理解。
有時“使用者”也會用在根本沒有人機互動的地方，如圖15。一個定時收集資訊的系統，根本不需要和人互動，但需求人員也會說“使用者是怎麼要求的？多長時間收集一次？速度要多快？源格式和目標格式是怎樣的？”此時，“使用者”不是指和所研究系統互動的人，而是系統所服務的目標組織的某個負責和開發團隊介面的人。例如，假設這個系統為某市國稅局服務的，需求人員剛才說的“使用者”可能是國稅局資訊中心的副主任。怎樣稱呼這位副主任才正確，後文再說。
圖15 無人蔘與互動的收集過程
“使用者”一詞存在的問題：
（1）很多時候我們口中的“使用者”是隨意推測的。
我們來看圖9的餐館的例子。我們把它搬到圖16。假設圖16是餐館的現狀，餐館的老闆希望在此現狀之上進一步改進。需求人員很容易先入為主，認定上面的人就是新系統的“使用者”，然後逐個找這些“使用者”調研。
圖16 餐館的現狀
這樣的先入為主是不對的。也許餐館老闆希望看到的改進如圖17所示。從圖中可以看到，領位員這個崗位都不需要了，還找他調研個啥。如果連服務員都可以不要，老闆可能覺得更爽。
圖17 對餐館的一種改進
（2）“使用者”混淆了演員和觀眾。
我們先來看用例（Use Case）的一些概念。如圖18所示，用例把軟體系統看作一部電影，演員（Actor，執行者）在臺上表演，觀眾（Stakeholder，涉眾）在臺下看，觀眾按照他們的地位排排坐。演員在臺上表演什麼是由觀眾的口味決定的，先照顧前排的觀眾，如果有餘力，再照顧後排的觀眾。
圖18 演員（執行者，Actor）在臺上表演，觀眾（涉眾，Stakeholder）在臺下看
用例使用“執行者”（Actor）和“涉眾”（Stakeholder）代替了原來的“使用者”，這是一個非常大的突破。“使用者”這個詞混淆了演員和觀眾的區別。過去經常說“找使用者調研需求”，這是錯誤的。所謂“使用者”，就是上臺表演的人類演員。找使用者調研，相當於找演員問劇本應該是什麼內容，豈不是很荒謬？劇本應該由編劇向觀眾調研編寫出來，然後由各路演員在臺上演繹。
演員如果是人類，那麼在觀眾席上也會有一個位置，不過在第幾排就不知道了。范冰冰這樣的大咖，可能有能力影響劇本的內容，跑龍套的就算了吧。
在臺上當“使用者”當得越歡的涉眾，往往在涉眾排行榜上排位越靠後。您想想，整天操作電腦搞得手僵脖子硬的“使用者”，有幾個是職位高的呢？真正位高權重的涉眾，雖然偶爾也會上臺表演，但更多時候是坐在臺下看戲。建模人員如果過多地關注“使用者”，花在重要的前排涉眾身上的時間可能就不夠了。
像“使用者故事”這樣的方法在開發一些面向大眾的網際網路系統時還能應付，因為這類系統的執行者往往屬於前排涉眾，以上問題就被掩蓋了。如果開發涉眾較多、利益衝突微妙的系統，應該採用用例這樣更嚴謹的需求技能。例如做一個手機遊戲，重點調研玩家這個“使用者”是可以的，做一個某單位的櫃檯系統，也重點調研視窗工作人員（希望幹活越少越好），那背後的領導和其他同事就遭殃了。
另外，現在的系統做出來，越來越多的介面不是面向人類的，而是面向另一個軟體系統，也就是說沒有“使用者”。兩個電腦系統互動的需求，難道就不用做了，或者可以隨便做？非也。那只是相當於上臺表演的不是人，是功夫熊貓、變形金剛和喜羊羊灰太狼，但是臺下對錶演說好說壞的觀眾依然是人。建立“執行者和系統在臺上表演，涉眾在臺下看錶演”的概念，在執行者為非人系統時對捕獲需求很有幫助。
（3）“使用者”是拒絕深入思考的遮羞布。
即使是演員和前排觀眾重疊的系統，“使用者”也是一個阻攔需求人員深入思考的詞彙。許多產品經理把“使用者”掛在嘴邊，“要從使用者的角度思考”，“使用者滿意的才是好產品”等等，甚至還有“賈伯斯不在意使用者的意見”等奇談怪論。問題來了，誰是使用者？
一個老頭找到PS可樂公司，告訴他們的主管，“我可是你們的忠誠客戶啊！我喝過的可樂罐排成線，可以從蘋果園排到通州（北京從西到東）。現在我老了，我對你們的可樂下一個版本提出如下要求：第一，我有胃病，下一個版本不要有這麼多氣；第二，我有糖尿病，下一個版本里面不要有糖。”PS可樂公司的主管很感動，哇，這麼棒的顧客，把要求提得那麼具體，省下好多我們調研需求的時間，好，下個版本就這麼辦！
可惜，現實生活中不會有這樣的場景。老頭老太太可以買可樂喝，甚至可以買給自己的寵物喝，PS可樂公司不會攔著。問題在於，老頭老太太提的要求，或者為他們的寵物提的要求（注意用詞：是要求，不是需求），PS可樂公司不會放在重要的位置來考慮，因為PS可樂的目標人群是青少年。可惜，很多時候我問需求人員：“可樂賣給誰？”得到的回答大多是“賣給消費者”，“賣給想喝可樂的人”等對做出好賣的可樂沒有幫助的、正確而無用的廢話。
我在《軟體方法》中，用“老大”取代了“使用者”。“老大”是一個真實存在的具體的人。定位“老大”的具體方法參見《軟體方法》第2章，和Persona方法類似。但是Persona是虛構一個“使用者畫像”，說白了也是鼓勵需求人員逃避深入第一線調研的辛苦，安心閉門造車。例如，為女性做一個產品，建模人員深入第一線調研，面對的調研物件是一個個具體的女性。如果建模人員把調研的精力花在羅玉鳳身上，留給林志玲的精力就不多了，所以必須思考羅玉鳳更像老大還是林志玲更像老大的問題。相比起來，關在辦公室隨意捏造一個符合自己要求的“女性”省事多了。如果滿足於Persona，歸根結底還是在內心裡沒有認識到深入第一線調研的重要性。
“老大”的頭腦是一塊塊的戰場，所研發的系統是一支軍隊。研發團隊的領導是軍隊指揮官，他負責找到自己的軍隊最值得投入的戰場，指揮軍隊和敵人廝殺，佔領戰場，或者防守住敵人的進攻。戰局是殘酷的。您手上的三萬紅軍下一步應該殺向哪裡，可選項其實少之又少，您必須竭盡全力把這個戰場找出來。可惜，許多人低估了現實的殘酷，意淫自己手裡有百萬大軍，愛殺往哪裡就殺往哪裡。
圖19 和對手在老大的大腦裡廝殺
需求（Requirement）。明確術語，不再單獨闡述。
使用者需求。錯誤術語。需求指系統對外提供的功能效能，如果要在“需求”前面加一個定語，這個定語是“系統”——“系統的需求”。
系統的需求就像電影的劇本，規定了電影拍出來必須滿足的內容，它是平衡了各種觀眾的口味（先照顧第一排觀眾，再照顧第二排……）得到的結果。對所有觀眾、演員來說，劇本就在那裡，不會因為某個觀眾不喜歡其中某個情節而變化，也不會因為暫時還沒有找到演員來拍成電影而變化。所以，不存在什麼“使用者需求”、“設計需求”、“架構需求”、“開發需求”、“編碼需求”等東西。需求不是你的、我的、他的，是系統的，是你我他最終達成的關於系統的一份契約。
那麼，“使用者”後面能跟什麼呢？可以跟“要求”。更嚴謹的術語是“涉眾利益”。需求像電影劇本，涉眾像電影觀眾。劇本只有一份，觀眾卻是多種多樣，不同觀眾的欣賞角度和口味不同。魯迅說過：一部紅樓夢，經學家看見《易》，道學家看見淫，才子看見纏綿，革命家看見排滿，流言家看見宮闈祕事。
軟體系統也是如此。例如一個生產執行管理系統，老大製造部王部長關注的是“縮短從接到市場部訂單到交付產品的時間週期”，車間工人更關心“我這個崗位的工作量會不會增加”，庫管員可能擔心“以後不好搞手腳”。系統的需求首先要照顧王部長的利益，在不損害王部長利益的前提下，還有餘力的話再照顧車間工人和庫管員。對於實在照顧不到的後排涉眾，很多時候只好抱歉了，這個系統可能會損害你的利益。
軟體的需求規約相當於電影劇本。電影劇本不是由觀眾直接提供，而是由編劇根據不同觀眾的口味編出來的。同樣，軟體需求不是由涉眾直接提供的，而是由需求人員綜合不同涉眾的利益來決定的。涉眾沒有資格提供需求。
系統的需求是平衡各種涉眾利益得到的，不由單一涉眾決定。以ATM機為例，如果需求人員詢問ATM機的執行者儲戶“取款機應該怎麼做你覺得最好”，儲戶回答大實話“最好像我家抽屜一樣拉開就拿，喏，把我家裡的抽屜拿去做原型”，需求人員顯然不能把這個“抽屜”當真，只需要把“抽屜”背後的涉眾利益提煉出來——儲戶希望操作次數儘可能少一些。最終系統的需求有多少尊重了這個利益，就要看儲戶在涉眾排行榜上的排位了。
拿患者和醫生類比也可以幫助理解。患者到醫院對醫生說“我腿疼，可能得了腿癌，我要做放療”，醫生就給他做放療？顯然不是這樣，醫生只能把患者所說的一切當成素材，按照成熟的套路，該做什麼檢查就做什麼檢查，該如何治療就如何治療。
很多時候我們想涉眾調研時，涉眾直接給出解決方案——“我要一個像某某軟體那樣的！”如果你真的按照他說的做了，他用的時候又不滿意了，而且他的其他同事更不滿意。然後我們還委屈呢，都是按照當時開會時你說的做的，還有錄音為證！
瞭解到“涉眾無資格提供需求，和涉眾交流的內容應該聚焦於涉眾利益”，可以幫助我們少犯錯誤。
術語04：文件
評價：“文件”屬於模糊術語。
先列出使用“文件”的一些話語：
你們怎麼一上手就寫程式碼，連個文件都沒有！
你現在在做什麼？我在寫文件。
程式碼就是文件。
從以上話語可以看出以下問題：
（1）在許多軟體開發人員的大腦裡，“文件”的意思就是“程式碼之外的其他工件”。由於缺乏軟體工程方面的基本知識，對之前提到的“A-業務建模”、“B-需求”、“C-分析”、“D-設計”等工作流沒有概念，只好把軟體開發工作分為“寫程式碼”和“寫文件”兩部分。（其實，就連什麼叫“程式碼”，很多人也是糊塗的，這一點後面再說。）
（2）軟體開發人員一旦把工件簡單分割為“程式碼”和“文件”，還會導致這樣的誤解：認為“文件”只不過是“程式碼”的一種比較概要或比較形象的表現形式，不同的“文件”代表著“程式碼”的不同檢視，可以讓開發人員從不同的視角觀察程式碼，這樣就便於人腦把握程式碼的複雜性。如圖20所示。
圖20 誤解：文件只是程式碼的檢視
這種誤解不只“普通”的開發人員會有。Martin Fowler所著的UML暢銷書《UML精粹》，認為UML有三種用法：草稿、藍圖和程式語言，也是僅從編碼的角度來說的。從Fowler寫作的其他書籍《重構》、《企業應用架構模式》、《分析模式》等可以知道，他的研究工作集中在分析設計工作流，在業務建模和需求方面研究不多。
這樣的誤解就會導致推論：只要“程式碼”寫得自己“會說話”，那麼“程式碼就是文件”，“文件”就不需要了。本來“文件”就是“程式碼以外的其他東西”，這麼一推，就變成了“程式碼就是一切”。
（3）把“文件”當作“程式碼”的檢視還會帶來下面這種思維顛倒：先拍腦袋實現，然後再從實現反推其他工作流的內容。例如下面的對話：
張三：這個不應該是系統的用例（如果您不理解什麼叫“用例”，就先把它理解為“功能”好了）。
李四：是的！我都寫好了，執行一下給你看，這個系統確實提供了這個用例。
是否系統的用例應該以“好賣”來判斷。權衡涉眾利益之後覺得應該有，系統就有，不該有就沒有，而不是我寫好了程式碼，所以就應該有。
張三：這兩個類關係不應該是泛化，而是關聯。
李四：是泛化，不信我開啟程式碼給你看，或者逆向工程轉出類圖給你看。
是否泛化關係應該以“符合領域內涵”來判斷，而不是先寫好程式碼“人是豬的一種”（肯定編譯通過），再用寫好的程式碼來證明“人是豬的一種”。
（4）“文件”還意味著它和“程式碼”使用的可能是不同的工具寫出來的。在Visual Studio、Eclipse裡面寫出來的叫“程式碼”，在Word、wiki、Visio、EA等等裡面寫或者畫出來的叫“文件”。
正確的理解是：
不同工作流產出的工件之間的區別不在於形式，而在於思考和表達的內容，如圖21所示。
圖21 建模工作流思考內容
如果清楚瞭解“區別在於內容”這一點，就知道“我在寫文件”這樣的話只是表達“我正在用文件編輯工具在工作”，沒有其他意義。你在寫什麼文件？“業務建模”？“需求”？“分析”？“設計”？我不寫，我畫圖難道不可以嗎？我不寫不畫，我用語音清楚地表達出組織的流程，不可以嗎？更有意義的說法應該是“我在做業務建模”。如果說“文件”二字可以給您帶來不可替代的快感，可以說“我在寫業務建模文件”。
內容和形式的組合是靈活的。很流行的“程式碼就是設計”這句話的意思就是，設計工作流目前推薦的做法是不需要畫UML圖或者寫“設計文件”，直接用原始碼來表達設計模型。編碼本身就是一種建模工作。計算機執行的是二進位制指令，原始碼實際上也是“模型”。之所以被稱為“原始碼”，是因為它是人腦需要編輯的最低形式模型（編輯完這個就好，後面的事情就可以交給計算機了！）。這個最低形式模型隨著時代的發展不斷變化。
如圖21所示，最初的原始碼是機器語言。程式設計師在紙帶或卡片上打孔來表達0和1。後來發現這樣太累了，於是發明了一些助記符，這就是組合語言。 今天會有開發人員故意裝×，“這些我不太懂唉，我是做底層的，用C編碼”，可是C語言卻被歸類為“高階語言”，因為類似C這樣的語言出現的時候， 大多數程式設計師編輯的是組合語言，C相對於彙編來說，當然很高階。今天的一名企業應用程式設計師，最終需要編輯的可能有 HTML、CSS、JavaScript、Java、配置指令碼、SQL等，這些就是現在的“原始碼”的形式。
圖22 “原始碼”的發展歷程
從圖22中的“歷史程式”來看，大趨勢是人腦要編輯的“原始碼”離計算機原來越遠，離領域越來越近。至於最終什麼樣的具體形式能成為下一形式的代表，只好看各種語言的“個人奮鬥”了。
同理，如果人腦只需要編輯UML模型就可以實現系統，那麼“模型就是原始碼”。例如用帶有設計級除錯和強大程式碼生成能力的工具IBM Rational Rhapsody開發實時嵌入系統，在配置好和IDE的整合之後，人腦只需要編輯和除錯UML模型（主要是類圖和狀態機圖），就可以實現系統，不需要在IDE裡敲字元。感興趣的讀者可以自己去看Rhapsody附帶的例子。
“程式碼就是設計”可以，那麼“程式碼就是需求”可以嗎？當然也可以。例如，把整個系統看作一個類，那麼這個類的操作就是系統的需求，因為它表達的是系統作為整體提供的服務。
我們在使用UML建模的時候，各種建模元素和建模內容也是靈活匹配的。例如，狀態機圖，可能一看到就想起分析設計，其實也可以用來表達需求。圖23把“電視”作為整體來畫狀態機，表達的就是“電視”的需求。
圖23 用狀態機圖表達電視的需求（讀者可以自行思考圖中？處應該寫什麼。看起來一目瞭然，其實寫對不容易。）
當然，不同的內容有推薦的形式。各建模工作流可以選用的建模圖形以及推薦用法如前文圖2所示。