軟體工程中業務模式的使用（第二部分）

釋出日期 : 2005-10-22 | 更新日期 : 2005-10-22

Philip Teale

微軟公司

Robert Jarvis

SA Ltd

本文研究了怎樣去開發基于業務功能、資料、業務構件的業務模式，并且示範了怎樣利用這些業務模式來建構軟體系統。

本頁内容

介紹

業務功能

資料模型

業務模式和行業方案

結論：設計模式和行業方案的架構和方法

介紹

文章一共有兩個部分，旨在探讨是否能夠用一種結構化的方法去定義業務模式，如果能，這些業務模式又是否能夠為那些支援業務的系統建構者們提供有用價值。本文的觀點是這種價值是确實存在的。

文章的第一部分已經出版在刊物第二期上了，第一部分探讨了怎樣去定義對軟體工程師有用的業務模式。在這一部分中，介紹了企業結構架構SAM，來分析可能性，并得出以下結論：

• 業務模式支援業務功能
• 業務模式需要資料來支援描述業務功能
• 業務構件是業務所需要的資料和功能的IT代表
• 業務模式的結構應該能夠随意地支援業務功能、資料和構件。這在分布的企業、決策者或者應用不同技術和運作環境的機關都是非常必要的

而且，也給出了具有上述特點的業務模式的定義。

文章的第二部分描述了怎樣去開發基于業務功能、 資料和業務構件的業務模式，同時介紹了工程軟體系統中業務模式的使用方法。

第二部分摘要

本文用一個現實簡單例子來闡述開發業務模式所需的業務功能、資料、業務構件的标準方法。這裡并不讨論它的理論基礎，也不讨論理論之間的關系。文章的目标在于證明：“這種方法能夠被實作，并且知道怎樣去實作”，而不是提供具體的實作步驟。文章的開始，介紹了一種方法，來定義所需的業務功能、資料、業務構件，然後用PRM來指導接下來的整個過程。文中采用的例子是關于醫療行業的，但所用的技術是任何領域通用。并且這些技術也已經應用在實際的項目中。需要着重申明的是，不是必須刻意地使用這些技術，技術本身并不重要，關鍵的是結果。正是因為這些結果，才使得設計更加精确的模式和可傳遞的軟體系統成為可能。

模式和系統之間的不同點

如果沒有太多關于模式的經驗，那麼，你在閱讀這些例子的時候，就應該把它們看作是一個系統開發而不是模式，這是因為在軟體工程中，模式是開發局部系統的踏腳石。模式保證了從一個可靠的起點開發到最後的目标系統的部分方法。它看似簡單，實際上它本身也不是一種具體的解決方案而是抽象的，使得你不得不去建立一種符合自己需要的具體方案。建立模式時最謹慎的是正确擷取它的抽象層次，很少有抽象來限制模式的有效性，因為它是被逐漸具體化的。但是許多抽象也限制了模式的實用性，進而使得它提供的實踐價值比較少。

今天一個共同的趨勢就是設計一個叫“消息經紀人”的服務去提供消息的路線和保證各種IT服務之間的轉換。高度抽象的模式應該十分精确—如果想要提供消息的路線和保證各種IT服務之間的轉換，就用“消息經紀人”，它的益處在哪裡呢？這個思路雖然有些作用，但卻不能提供更多實際的幫助。

另一方面， 當銀行操作統一的顧客視圖時，我們建立一個消息經紀人來處理那些需要的IT服務。那麼，能夠稱這種方案為業務模式嗎？答案是肯定的，但是它有多少價值呢？這種方案太具體并可能存在潛在的可重複的方案，是以還是不能視之為業務模式。最有效的業務模式應當有這樣的優勢：能夠被抽象、反複地應用到系統建構時的各個層次中，解決許多行業問題。本文給出的業務構件規格書的例子就是醫療行業業務模式。我們應該能清楚地認識到業務模式的以下重要特性，即一些模式将對行業外并無益處（像本文中的例子），而另一些卻不（它們能夠代表通用的功能）

誠然，那些跨行業通用的業務模式确實能夠被相當成熟地用來識别某些行業領域，但那将是另外一種完全不同的讨論了

傳回頁首

業務功能

為了開發業務模式，我們首先必須發現、定義和文檔化相關業務功能。以下是主要任務：

1. 發現描述問題空間的原子功能集，在功能模組化裡稱之為“原始功能”，類似地，在業務過程重組裡稱作“基礎過程”
2. 把這些原子功能聚合成更大的更條理的功能組

“原子”的意思是功能不能夠被分解，一旦開始，功能就應該被完成和接受。

是以我們實際追求的業務模式是将業務功能定義在一種可以分解的層次，這些層次間有緊密聯系。特别是資料層，如果發現業務功能定義在整個體系結構的第四層，通常可以形成資料層實體間的CRUD（建立、讀取、修改、删除）關系。業務功能可以采用自底向上或者自頂向上或者二者混合的方式來分析和定義。

自底向上分析

分析員使用這種方法，聚焦使用者典型業務領域，去分析他們的業務過程。用例圖或者任何能表達業務過程中執行順序和并行任務的方法，将會被采用，随後，分類、分析過程集合。通常可以注意到，許多步驟或過程中執行的低層次的任務将在在不同的過程中被重複執行很多次。是以，必須識别這些多餘的任務，并且從原始功能的必要集合中排除出去。圖１用一個簡單的流程圖示範了這一過程。從圖中可知，任務Ａ是多餘的，應該僅出現在原始集合中一次，通過這樣類似的分析，最後得出必要的原始集合。再反複合并功能，得到如圖２所示的動态結果。從業務模式的角度考慮，自底向上的分析方法存在一些問題。

圖１　過程的發現和合成

1. 對于包含許多使用者的龐大過程，自頂向下地分析過程工作量非常大（為了減輕工作量，一種折衷的辦法是，采用過程分析和用例分析相結合的方法來提煉過程）
2. 過程的本質在于對“像-是”的情況的分析，隻要這種分析足夠清晰，它的結果就可以接受。
3. 為了確定業務模式的正确性，必須在相同的領域範圍内進行反複的分析驗證。在這個過程中就會發現很多實際的問題。

自底向上的分析方法的好處在于，基礎分析為驅動業務模式方案奠定了基礎，驗證業務模式的關鍵在于成功地實踐，一旦選好了執行個體，自底向上的分析方法的這些優勢就會有明顯展現。

自頂向下分析

圖2中的功能分解依靠另外一種方法——自頂向下分析方法來進行，這種方法首先假定最上層的結構，然後逐漸填充下面的層次，直到充分詳細為止。

圖2 業務功能分析的典型執行個體

很明顯，有必要對分析的結果進行驗證，看它是否正确地反映了現實世界。是以，自頂向下的分析方法從描述最抽象的業務問題領域開始，然後逐漸分解，直到最原始層為止，以此來驗證結果的正确性。這種方法能夠通過一種标準方法來實作，就是用于功能模組化的IDEF0，或者用于業務過程模組化的擴充UML也可以。

事實上，很多前因後果決定了自頂向下的分析方法不需要詳述業務過程。

自頂向下的分析方法在模式定義中的好處是行業顧問完全能做這項工作，這些顧問們往往有和許多客戶在某個問題領域打交道的許多經驗，是以有他們來完成這項工作将會既準确又迅速。本質上，這種分析方法一方面執行了和專家進行知識挖掘的任務，另一方面，它也減少了必須直接分析的執行個體數目，改變了分析員的角色——不再是以前的從業人員而是現在的浏覽者。

混合分析方法

實際上，我們經常把自頂向上和自底向上的分析結合使用，在過程綜合到層次結構低層次分解之間反複的變換。這樣做的好處是，可以用自底向下擷取的現實世界功能來驗證假設的自頂向下的分解。實踐證明，這是最快、最可靠的方法。

功能分解執行個體

以下是關于病人醫療情況的執行個體，使用上述方法來進行業務分析，進而示範了核心業務模式的形成過程。

首先，分析問題領域的功能性需求。以乳房癌治愈為例，得出40多個過程，參與的角色有病人、醫生、系統管理者和機密保管員等。其中機密保管員這個角色會随着資訊的機密性改變而改變。這些過程是用UML用例來文檔化的。它們在許多用例中都有相同或者相似的子活動高度地重複。是以，我們抽取并整理了這些活動，形成以下清單：

• 病人登陸（使用者檢查）
• 病人登出（核查）
• 搜尋申請的病人
• 管理病人詳細資訊
• 管理病人權利
• 檢視私人區域
• 檢視個人GP詳情
• 管理個人一般健康資料
• 管理捐贈人明細
• 管理病人明細
• 管理家庭成員
• 檢視采取的免疫措施和種痘
• 管理個人權利
• 檢視病人病厲
• 檢視病人私人區域
• 申請病曆
• 複查病曆
• 建立病人事件
• 管理病人個人事件
• 建立病人療程
• 檢視病人療程
• 檢視個人病曆
• 定義普通協定
• 管理個人協定
• 維護醫療項目
• 執行醫療代碼翻譯
• 擷取其它醫療代碼
• 編制其他醫療代碼
• 維護醫療路徑
• 管理預約
• 改變預約
• 通路事件明細
• 通路系統索引
• 維護臨床過程
• 維護角色定義
• 維護組/隊結構
• 維護組/隊成員
• 維護許可證授權
• 維護醫生注冊
• 醫生登陸（身份鑒定）
• 醫生登出（核查）
• 檢視醫生許可
• 維護具體許可
• 定義普通許可

圖 3 醫療執行個體—功能分解

圖三表達了醫療執行個體功能分解過程。利用主題和功能的相似性把各個分散的功能歸納到更高的層次上去。

傳回頁首

資料模型

醫療執行個體有綜合的資料模型。經過對同一個問題領域的資料進行分析，共定義了31個主要的實體，如病人、醫生、病人事件、醫療路線等等。資料模型需要識别實體的候選碼和它們的主要屬性，描述實體之間的互相關系，分解所有的多對多的關系。并且這些操作就是在功能分析時并行地得到的。

據我們所知，資料模型應該支援所有已識别的功能需求，反之亦然。在實體之間的互相關系和聚合的基礎上，上述31個實體已經配置設定給8個資料項。這些項分别是：

• 病人
• 病人協定
• 醫療路線
• 醫療項目
• 臨床過程
• 角色、團隊群組織
• 醫生和許可
• 本地系統

這些資料項是目标資料庫和動态内容定義的第一步。圖4顯示病人資料項的全部内容，采用傳統的E-R圖描述了資料實體以及實體間的關系，并且标出了每個實體的主鍵。框外的實體是屬于其它資料項的，但是與框内的實體有着緊密的聯系。

圖 4 病人資料項的執行個體模型

映射關系

功能分解的層次結構定義了需求功能，關系資料模型定義了需求資料。此後，我們通過比較功能和資料二者之間的關系，能夠得出一個初步的構件體系結構。具體的做法是建立一個矩陣，行表示功能，清單示識别的實體，行列交叉處的值有C、R、U、D四種：

• C代表“建立”資料實體執行個體的功能
• R代表“讀取”資料實體執行個體的功能
• U代表“修改”資料實體執行個體的功能
• Ｄ代表“删除”資料實體實力的功能

得出的結果如下圖5所示：

圖 5 功能和資料的 CRUD 的矩陣

矩陣簇群

我們確定矩陣中每一列（資料實體）至少有一個建立操作，每一行（功能）都有少許活動。請注意矩陣中的操作并不是絕對正确的，特别是讀取操作。同時表中沒有制定删除操作。現在用歸類和聚合的方法來分析矩陣，以擷取那些共享建立和修改操作的功能組和實體組。對于資料模型中内部實體動靜态關系，我們采用高内聚、低耦合的原則進行功能分解。然後調整矩陣，合并關系緊密的功能和實體，最後得到的就是候選業務構件。具體的算法描述（"North West"算法）超出了本文的範圍。圖6所示。

圖 6 矩陣簇群

業務構件的來由

首先應該說明業務構件是用來做什麼的。一個業務功能建立、讀取、修改和删除資料。分組聚合相同資料實體的建立和修改功能，用諸如互相的分簇技術定義一個必要的構造塊，就形成了業務構件，用它來構造模式、系統或應用，以便支援特定的業務過程。業務構件是一個驅動領域的執行個體——它是從其它2個領域的互相關系中推導出來的。這是一個強大的技術，可以擷取企業體系結構中隐藏的特性。通過封裝功能和資料到一個構件中，軟體重用和重構才能切實可行。更進一步說，業務構件提供了一些服務，使得它們能夠和其它業務構件提供的服務相結合一起協調的工作，完成一個具體的應用。

業務構件來源于對服務和接口的簇群分析，業務實體構件、資料通路構件和某些服務代理這些制品共同構成了.Net體系結構，業務構件并不包含靈活的元素如UI構件和UI過程構件、業務工作流或其他元素，如安全、運作管理和互動。這些初步的定義是十分有用的。它提供了一個全部體系結構方案的穩定部分。然後結合一些靈活元素，像UI、UI過程、業務工作流，就能提供一個以穩定模式為基礎的靈活方案。

通過對業務功能和資料之間的整合分析，能夠得出初步的業務構件和服務。進而生成CRUD矩陣，來定義構件與資料之間的關系

圖 7 業務構件樣例

在SAM中，業務構件也是一個層次，是以業務構件能夠被分解成更為具體的服務、業務實體、資料通路子構件層，并且包含想要業務服務。對這些服務進行明确的定義是非常有用的，這樣才能夠搞清楚哪些是internal服務，哪些是web服務

構件和服務

構件清單如下圖：

• 病人構件
• 病人事件構件
• 病人協定書構件
• 醫療項構件
• 預約構件
• 療程構件
• GP&醫院系統通路組建
• 臨床過程構件
• 組/隊構件
• 醫生構件
• 許可證構件

圖 8 PRM 的體系結構視圖和設計視圖

上述構件顯示了業務模式定義的本質，其中的病人構件如下圖7所示，它描述了整個構件的功能、管理的資料和服務、特征。

業務模式對軟體工程有什麼作用？

現在我們将來讨論本文的關注點——怎樣利用上述業務模式來建造其它模式或實際的軟體系統。圖8的PRM的五個層次說明了這個問題。注意到PRM區分了系統結構視圖（一個更高的視圖，如項目規劃）和系統設計視圖（如項目或主題設計）。圖8介紹了适合這些視圖的不同技術和标記，幫助建立一個正确的軟體系統。值得注意的是，PRM辨識簡單的元素時，要依靠實踐而不是假定或者臆斷。在業務模式定義後，就可以随心所欲地開展工作了。

在對業務模式進行仔細分析時，首先需要認清體系結構和設計之間抽象水準本質的不同。

業務模式用在哪些地方比較适合？

圖9顯示了業務模式的優勢，圖中定義了業務、業務功能、資料和業務構件這些穩定元素。這種方法可以用來指導大型項目開發，保證了項目之間的一緻性，節約了項目開發成本。

圖 9 PRM 中業務模式的優勢

業務模式和面向服務的體系結構（ＳＯＡ）

對于那些想要提供其它ＩＴ模式或者更進一步地提供業務問題的ＩＴ方案的人士來說，業務模式能夠用ＳＯＡ原理更深入地來定義，ＳＯＡ雖然不是必須的，但确實最優秀的。利用ＳＯＡ來定義業務模式，我們所需要做的事就是将體系結構中的詳細内容轉化為ＩＴ方案。那麼首先需要提供給業務靈活一個機會，如圖１０所示，将下一層描述的業務細節包含到模式中來，圖中新加的這兩套原理将把業務模式改變成業務方案模式，另外，業務可以為業務模式構造一個具體的業務方案體系結構。下面我們就來讨論這個問題。注意，此時各個階段的工作仍然是獨立的技術産品

圖１０　在業務模式中附加ＩＴ體系結構

業務模式、SOA、(Microsoft)産品細節

最後，圖11清楚地描述了更深層次的産品和實踐，成功地實施了微軟技術方案

圖 11 附加微軟技術元素

到目前為止，我們已經講述了業務模式、面向服務的應用體系結構和微軟的一套實施模式，接下來将利用相關的模式或IT方案來解決體系結構層次的共同問題。但是仍然需要更加詳細的資訊，它就是設計視圖。

傳回頁首

業務模式和行業方案

上面已經讨論了體系結構的建立過程，并且這個過程保證了IT項目的管理和價值。如果想要提供一個具體的方案，那麼就需要對體系結構的設計層次更詳細的研究。将一個方案應用到幾個項目上是有可能的，并且體系結構保證了這些項目之間的一緻性。

圖 12 精化設計方案

圖12顯示了設計方案的精化過程，并告知用UML這個标準的方法來進行系統設計。

這是精化體系結構的一個普遍的方法，設計結果可以直接用來實作。

在精化體系結構的時候，還能産生一個模式，即IT設計模式。今天大多數軟體模式的描述也是采用上述這種方法。包括Microsoft公司的企業方案模式—Microsoft .NET6和Martin Fowler的企業應用體系結構模式。

當然，并不是僅僅依靠設計模式就能建立一個實際的解決方案的，找出模式之間的關聯性這一步也是相當關鍵的。這些模式涉及到Gang of Four8或面向模式的軟體體系結構集，以及上面提到的Microsoft和Martin Fowler的模式等。

傳回頁首

結論：設計模式和行業方案的架構和方法

本文描述了建立業務模式的架構和方法，然後使用業務模式來實作指定的體系結構，這種體系結構可以用來定位、核算、管理IT項目。并且提供了一種方案，來更進一步地指導該體系結構的設計和實施

Microsoft技術模式的執行個體可以在此處獲得，http://www.microsoft.com/resources/practices/

尾注：

1. 本文對模式的定義遵循由Christopher Alexander在《建立永恒的構造方法》（牛津大學，1979）一文中建立的模式标準。描述模式時采用一種Coplien-style的标記。
2. 對于SAM更詳細的資訊，請檢視《企業體系結構—對Bigger Picture的了解》，Bob Jarvis，牛津大學計算機中心，UK, 2003年5月，或者檢視http://www.systems-advisers.com
3. 模型問題精化—檢視本刊2出版的第一部分
4. NIST中 FIPS 的IDEF 成員标準，檢視此處文章183頁http://www.itl.nist.gov/fipspubs/by-num.htm
5. .Net的應用體系結構：設計應用、服務模式和實踐指南—Microsoft 公司 2002
6. 檢視http://www.microsoft.com/resources/practices/ or 或者Amazon
7. http://www.martinfowler.com/books.html#eaa
8. 《可重用的面向對象軟體設計模式原理》，Erich Gamma, Richard Helm, Ralph Johnson, 和John Vlissides. http://hillside.net/patterns/DPBook/DPBook.html

慎重聲明：

未經本文作者所在公司授權，任何其他公司都不得擅自采納文章中的思想和理念。

作者介紹：

Philip Teale是一位夥伴政策咨詢師，之前供職于英國微軟的Enterprise & Partner集團，現就職于微軟Prescriptive Architecture 集團，之前為微軟提供咨詢服務，有29年的IT從業經驗，其中有4年供職于微軟，16年供職于IBM，均承擔軟體開發業務。他的國際性經驗包括了9年在美國工作，3年在加拿大，17年在英國。Philip Teale的背景是架構師、設計師和能建構大型複雜分布的商業系統。他最近的對上司思想産業的貢獻将推動微軟在企業系統模型建立上的發展，他是RSA會員。可以通過E-mail與他取得聯系：[email protected].

Robert Jarvis是系統顧問有限公司的總監，這是一家英國的顧問公司，專業從事為國際性大型企業開發戰略系統建設的業務。他也是一位微軟的建築咨詢合作人，Robert Jarvis在國際性系統咨詢方面具有超過30年的工作經驗，在英國、歐洲大陸和美洲為商業和政府組織提供咨詢。他特别擅長企業系統機構的建構，特别是業務/技術交叉點上。他是企業建構的創造者——對大型圖紙的了解，一篇很好的應用指南，于2003年，由英國國家計算中心出版。E-mail：[email protected]