| 2004 年 6 月 01 日
面向服務(wù)的體系結(jié)構(gòu)（SOA）和 Web 服務(wù)的基本觀念是成為我們?nèi)粘ＵZ言的一部分，并可看作是適于設(shè)計(jì)現(xiàn)代企業(yè)應(yīng)用程序的體系結(jié)構(gòu)形式。在這種背景下， 什么構(gòu)成好的服務(wù)這個(gè)基本問題就成為確保成功實(shí)現(xiàn) SOA 的關(guān)鍵。 像 面向?qū)ο蟮姆治雠c設(shè)計(jì)（Object-Oriented Analysis and Design，OOAD）、 企業(yè)體系結(jié)構(gòu)（Enterprise Architecture，EA）框架和 業(yè)務(wù)流程建模（Business Process Modeling，BPM）這樣的現(xiàn)有建模規(guī)則為我們提供了高質(zhì)量的實(shí)踐，可以長(zhǎng)期幫助標(biāo)識(shí)和定義體系結(jié)構(gòu)內(nèi)的適當(dāng)抽象。然而經(jīng)驗(yàn)表明，這些實(shí)踐各自單獨(dú)應(yīng)用時(shí)達(dá)不到要求。 在本文中，我們將研究 OOAD、EA 和 BPM 中的適當(dāng)原理。我們還將推動(dòng)對(duì)混合方法的需求，這種方法把所有這些規(guī)則中的原理與許多獨(dú)特的新原理組合起來。這樣得到的交叉學(xué)科 OOAD 方法使成功地進(jìn)行 SOA 開發(fā)更容易，我們稱之為 面向服務(wù)的分析與設(shè)計(jì)（Service-Oriented Analysis and Design，SOAD），它還有待正式定義。我們還只是剛剛跨入 SOAD 的殿堂。
在發(fā)現(xiàn)新的商機(jī)或威脅的預(yù)期下，SOA 體系結(jié)構(gòu)形式旨在提供企業(yè)業(yè)務(wù)解決方案，這些業(yè)務(wù)解決方案可以 按需擴(kuò)展或改變。SOA 解決方案由可重用的服務(wù)組成，帶有定義良好且符合標(biāo)準(zhǔn)的已發(fā)布接口。SOA 提供了一種機(jī)制，通過這種機(jī)制，可以集成現(xiàn)有的遺留應(yīng)用程序，而不管它們的平臺(tái)或語言。 從概念上講，SOA 中有三個(gè)主要的抽象級(jí)別：
早期的 SOA 實(shí)現(xiàn)項(xiàng)目經(jīng)驗(yàn)表明，諸如 OOAD、EA 和 BPM 這樣的現(xiàn)有開發(fā)流程和表示法僅僅涵蓋支持 SOA 范式所需的部分要求。SOA 方法在加強(qiáng)已經(jīng)制定的良好通用軟件體系結(jié)構(gòu)原則（如信息隱藏、模塊化和問題分離）的同時(shí)，還增添了附加的主題，例如， 服務(wù)編排、 服務(wù)庫(kù)和 服務(wù)總線中間件模式，在建模時(shí)需要對(duì)它們給予特別的關(guān)注。 圖 1展示了現(xiàn)有的 EA、BPM 和 OOAD 建模方法的主要應(yīng)用領(lǐng)域，也是我們隨后討論 SOAD 的出發(fā)點(diǎn)。圖中的水平軸表示 項(xiàng)目生命周期階段；垂直軸表示不同抽象層或 領(lǐng)域之間的區(qū)別，而建?；顒?dòng)通常就是在其上進(jìn)行的。 圖 1. BPM、EA 和 OOAD 的位置  SOA 的遠(yuǎn)景是相當(dāng)容易理解的，因?yàn)樗募夹g(shù)基礎(chǔ)眾所周知。例如，在任何 SOA 工作中，應(yīng)用通用的軟件體系結(jié)構(gòu)原則和 OO 技術(shù)都是一個(gè)有效的開端。然而，正如我們已經(jīng)提到的，早期采用者最常詢問的問題是如何標(biāo)識(shí)正確的服務(wù)。如前所述，OOAD、EA 和 BPM 在各自獨(dú)立地應(yīng)用時(shí)不能提供滿意的答案，而這正是我們現(xiàn)在要說明的。 在由 Booch 和 Jacobson撰寫的開創(chuàng)性的書（大約 10 年前出版的）中介紹的 OOAD 方法在定義 SOA 方面提供了非常好的起點(diǎn)。同樣地，雖然許多年來在體系結(jié)構(gòu)層次中應(yīng)用 OOAD 技術(shù)和統(tǒng)一建模語言（Unified Modeling Language，UML）表示法是一個(gè)常見的實(shí)踐，但是 OOAD 還是與像類和單獨(dú)的對(duì)象實(shí)例這樣的微觀層次的抽象有關(guān)。由于每個(gè)問題域常常都創(chuàng)建單獨(dú)的用況模型，因此，應(yīng)用程序開發(fā)項(xiàng)目，這個(gè)企業(yè)的大方向在許多情況下變得模糊。此外，由于種種原因，用況模型并不總是與其對(duì)等的 BPM 保持同步。 諸如 Treasury 企業(yè)體系結(jié)構(gòu)框架（Treasury Enterprise Architecture Framework，TEAF）、 面向特征的領(lǐng)域分析（Feature-Oriented Domain Analysis，F(xiàn)ODA）和 Zachman這樣的 EA 方法都將城市規(guī)劃級(jí)的觀點(diǎn)加在解決方案體系結(jié)構(gòu)之上，但是并沒有解決如何找到易于重用且具有持久性的高質(zhì)量企業(yè)抽象的問題。 雖然 BPM 方法（如 BPMI）在功能工作單元之上提供了端到端視圖，但是它們通常都沒有觸及體系結(jié)構(gòu)和實(shí)現(xiàn)領(lǐng)域。例如，在像 用于 Web 服務(wù)的業(yè)務(wù)流程執(zhí)行語言（Business Process Execution Language for Web Services，BPEL）這樣的語言出現(xiàn)之前，BPM 表示法缺少操作語義。此外，我們還看到了許多流程建模與開發(fā)活動(dòng)彼此分離的情況。 最后，現(xiàn)有的規(guī)則中沒有一個(gè)可以解決如何為 SOA 啟用 現(xiàn)有的應(yīng)用程序的問題；大部分時(shí)間都采用自頂向下流程?，F(xiàn)有的系統(tǒng)通常都存放有大量的重要數(shù)據(jù)和業(yè)務(wù)邏輯，并且不能簡(jiǎn)單地加以替代。因此，為了研究包裝和重構(gòu)策略，必須對(duì)這些系統(tǒng)進(jìn)行自底向上的分析。因此，對(duì)現(xiàn)有應(yīng)用程序的考慮會(huì)將我們帶到中間相遇的流程。 由于這些原因的存在，所以需要混合 SOAD 建模方法。這種方法以最佳的方式組合了 OOAD、BPM 和 EA 中的原理，并且融入了一些具有創(chuàng)新性的原理。 圖 2展示了這種新的方法的 SOAD 資源（原理和技術(shù)）： 圖 2. SOAD 及其組成部分：OOAD、BPM 和 EA 將企業(yè)應(yīng)用程序和 IT 基礎(chǔ)設(shè)施發(fā)展成 SOA 可能是一個(gè)大的負(fù)擔(dān)，會(huì)影響多個(gè)業(yè)務(wù)線和組織單元。因此，需要應(yīng)用 EA 框架和參考體系結(jié)構(gòu)（如 開放組織體系結(jié)構(gòu)框架（The Open Group Architecture Framework，TOGAF））以及 Zachman，以努力實(shí)現(xiàn)單獨(dú)的解決方案之間體系結(jié)構(gòu)的一致性。 根據(jù)過去的經(jīng)驗(yàn)，大多數(shù)現(xiàn)有的 EA 框架都在一個(gè)或多個(gè)方面有限制。例如，如果主要的問題是表示技術(shù)設(shè)備的低級(jí)構(gòu)塊如何在宏觀層次互連，則無法獲得業(yè)務(wù)層流程或服務(wù)視圖。然而，在 SOA 的背景下，這種考慮問題的方式必須轉(zhuǎn)換為以表示業(yè)務(wù)服務(wù)的邏輯構(gòu)件為中心，并且集中于定義服務(wù)之間的接口和 服務(wù)級(jí)協(xié)定（Service Level Agreements，SLA）。 此外，許多企業(yè)級(jí)參考體系結(jié)構(gòu)和框架是相當(dāng)普通的，并沒有觸及設(shè)計(jì)領(lǐng)域。這樣的高級(jí)體系結(jié)構(gòu)無法為架構(gòu)師和開發(fā)人員提供具體的戰(zhàn)術(shù)意見，并且常常導(dǎo)致企業(yè)體系結(jié)構(gòu)和解決方案體系結(jié)構(gòu)之間出現(xiàn)根本性的分歧。 SOAD 必須幫助 SOA 架構(gòu)師定義服務(wù)前景的整體業(yè)務(wù)級(jí)視圖。這是當(dāng)今的 EA 框架所無法提供的，它們需要未來特定于 SOA 的增強(qiáng)； 按需操作系統(tǒng)（On Demand Operating Environment，ODOE） 是 IBM 針對(duì)這種趨勢(shì)制定的主要戰(zhàn)略。 BPM 是一個(gè)不完整的規(guī)則，其中有許多不同的形式、表示法和資源。另一種常用的技術(shù)是定義表示概念性流程流的 事件驅(qū)動(dòng)流程鏈，正如 Barker 和 Longman所定義的。這第二種技術(shù)使用了不同于 UML 的表示法。 此外，還有許多專用方法（如 BPM 技術(shù)）可能被咨詢公司和企業(yè)資源規(guī)劃（Enterprise Resource Planning，ERP）軟件包廠商視為具有競(jìng)爭(zhēng)優(yōu)勢(shì)。ARIS Implementation Platform 就是這樣的產(chǎn)品的一個(gè)例子。其他的方法包括： Line of Visibility Enterprise Modeling(LOVEM) 和 IBM 的組件業(yè)務(wù)建模（Component Business Modeling，CBM）戰(zhàn)略。 最近的趨勢(shì)是定義表示可執(zhí)行流模型（如 用于 Web 服務(wù)的業(yè)務(wù)流程執(zhí)行語言（Business Process Execution Language for Web Services，BPEL） ）的標(biāo)準(zhǔn)方法。BPEL 將流程的范圍從分析擴(kuò)展到實(shí)現(xiàn)。這樣的可執(zhí)行模型引發(fā)了一系列的新問題，其中包括：
必須利用所有現(xiàn)有的 BPM 方法作為 SOAD 的起點(diǎn)；然而，必須使用流程模型中用于驅(qū)動(dòng) 候選服務(wù)和它們的操作的附加技術(shù)來對(duì)其加以補(bǔ)充。此外，SOAD 中的流程建模必須與設(shè)計(jì)層用況建模保持同步，并且必須給出與 BPEL 有關(guān)的問題的答案。 OO 分析是一種非常強(qiáng)大且廣為贊譽(yù)的方法，同樣，SOAD 應(yīng)該盡可能多地利用 OO 分析技術(shù)。要將 OO 分析成功地應(yīng)用于 SOA 項(xiàng)目，您就必須一次分析多個(gè)系統(tǒng)。用況模型必須繼續(xù)扮演重要的角色。然而，SOAD 必須主要是 流程，而不是 用戶驅(qū)動(dòng)的。因此，SOAD 需要 BPM 和用況建?；顒?dòng)之間的強(qiáng)鏈接。 在 設(shè)計(jì)層，OO 的目標(biāo)是能夠進(jìn)行快速而有效的設(shè)計(jì)、開發(fā)以及執(zhí)行靈活且可擴(kuò)展的應(yīng)用程序。對(duì)象是軟件構(gòu)造，其行為就像它們建模的真實(shí)世界的實(shí)體。例如，顧客 (Customer) 將有名稱和聯(lián)系信息，并且還可能有一個(gè)或多個(gè)與之相關(guān)的帳戶對(duì)象。從 OO 的角度看，每件事情都是對(duì)象。 OO的基本原則是：
OO 支持應(yīng)用程序分析、設(shè)計(jì)和開發(fā)的完整生命周期：
目前與 SO 有關(guān)的 OO 設(shè)計(jì)實(shí)踐的主要問題在于，它的粒度級(jí)別集中在類級(jí)，對(duì)于業(yè)務(wù)服務(wù)建模來說，這樣的抽象級(jí)別太低了。諸如繼承這樣的強(qiáng)關(guān)聯(lián)產(chǎn)生了相關(guān)方之間一定程度的 緊耦合（因而具有依賴性）。與此相反，SO 范式試圖通過 松耦合來促進(jìn)靈活性和敏捷性。目前，在 SOA 中還沒有服務(wù) 實(shí)例的跨平臺(tái)繼承支持和一流的表示法來避免需要處理服務(wù)生命周期維護(hù)管理問題（如遠(yuǎn)程垃圾收集）。 這些考慮事項(xiàng)使 OO 難以與 SO 體系結(jié)構(gòu)樣式直接保持一致。然而，對(duì)于設(shè)計(jì)已定義的服務(wù)中的底層類和組件結(jié)構(gòu)，OO 仍然是一種有價(jià)值的方法。此外，許多 OOAD 技術(shù)（例如類、責(zé)任、協(xié)作（CRC）卡）也可以用于服務(wù)建模（如果它們提升到更高層次的抽象的話）。在本文后面，我們將回過頭來討論這一點(diǎn)。 圖 4展示了可見性層次和 OO、 面向組件和 SO 設(shè)計(jì)提供的重點(diǎn)之間的對(duì)應(yīng)關(guān)系。它還展示了在 SOA 和 SOAD 背景中它們之間的相互關(guān)系。 圖 4. 設(shè)計(jì)層次 至于表示法，統(tǒng)一建模語言（Unified Modeling Language，UML）——通過一些附加的定型（Stereotype）和概要加以增強(qiáng)——自然成為 SOAD 的重要基礎(chǔ)。 在使用 Rational Unified Process (RUP)——被認(rèn)為是支持迭代軟件開發(fā)的分析與設(shè)計(jì)的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要價(jià)值。然而，RUP 以 OOAD 的原則為基礎(chǔ)，因而使其不容易與 SOA 設(shè)計(jì)保持一致。從 RUP 的角度來看，系統(tǒng)的體系結(jié)構(gòu)是其通過已定義接口交互的主要組件的體系結(jié)構(gòu)。此外，這些組件還由逐漸減小到類級(jí)粒度的更小組件組成。相反，在 SOA 中，系統(tǒng)的體系結(jié)構(gòu)通常包括滿足普通 業(yè)務(wù)服務(wù)需要的無狀態(tài)、全封裝且自描述的服務(wù)組成，它更接近于映射到 BPM，如 圖 5所示。 圖 5. SOAD 服務(wù)定義層次 這些服務(wù)可能包括許多協(xié)作或編排服務(wù)。這并沒有排除 RUP 采用的 OO 觀點(diǎn)，而是在其上實(shí)現(xiàn)了另一個(gè)抽象層。這個(gè)超層的作用是封裝作為正式的跨層接口結(jié)構(gòu)中的 RUP 構(gòu)件（ 軟件服務(wù)）設(shè)計(jì)的組件。
在這一部分中，我們將更詳細(xì)地描述 SOAD 的需求，并且開始確定它的主題和原理。目的是將關(guān)于這個(gè)主題的討論引到進(jìn)一步的設(shè)計(jì)工作。進(jìn)一步的工作無疑需要形式化 SOAD 方法。 已經(jīng)為 SOAD 確定了下列需求：
一些通用原則或品質(zhì)因素已經(jīng)確定，并且可以作為 SOAD 中的設(shè)計(jì)基準(zhǔn)：
自頂向下的業(yè)務(wù)級(jí)建模技術(shù)（如 CBM）可以為 SOA 建?；顒?dòng)提供起點(diǎn)。但是正如我們?cè)谇懊嫣岬降?，SOA 實(shí)現(xiàn)很少是在全新的項(xiàng)目中開始的；創(chuàng)建 SOA 解決方案幾乎總需要涉及集成現(xiàn)有的遺留系統(tǒng)，方法是將它們分解成服務(wù)、操作、業(yè)務(wù)流程和業(yè)務(wù)規(guī)則（同時(shí)參見 圖 6）：
圖 6. 服務(wù)分解 所有的 OOAD 都同標(biāo)識(shí)和定義服務(wù)有關(guān)；但是還需要具有更高層的觀點(diǎn)。此外，當(dāng) SOA 致力于比經(jīng)典開發(fā)項(xiàng)目層次更高的開發(fā)時(shí)，就有了發(fā)揮其他創(chuàng)造性思維的空間。 直接和間接業(yè)務(wù)分析 過去的經(jīng)驗(yàn)表明，這條主要的途徑應(yīng)該通過補(bǔ)充 間接技術(shù)來加以改進(jìn)。在選擇候選服務(wù)時(shí)，產(chǎn)品經(jīng)理和其他業(yè)務(wù)領(lǐng)導(dǎo)應(yīng)該進(jìn)行協(xié)商。例如，什么是計(jì)劃付款和開票模型？應(yīng)該商議假定使用正在構(gòu)建中的系統(tǒng)的企業(yè)的組織結(jié)構(gòu)圖。建議還考慮一下非 SOA 項(xiàng)目中任何現(xiàn)有的用況模型。用于對(duì)正在構(gòu)造的系統(tǒng)進(jìn)行營(yíng)銷介紹的術(shù)語是另一個(gè)很好的關(guān)于服務(wù)操作候選者的來源（特別是動(dòng)詞，很少關(guān)注營(yíng)銷動(dòng)詞?。?。 域分解 服務(wù)粒度 命名約定 除了組合 OOAD、BPM 和 EA 技術(shù)之外，還有幾個(gè)重要的 SOAD 概念和方面有待充實(shí)：
服務(wù)分類和聚合 服務(wù)組合可以通過可執(zhí)行模型（如 BPEL 建模的模型）來加以簡(jiǎn)化；這是傳統(tǒng)的建模工具和方法不能處理的事情。 策略和方面 除了已經(jīng)制定的良好 體系結(jié)構(gòu)可跟蹤性原則之外， 業(yè)務(wù)可跟蹤性也是一個(gè)理想的品質(zhì)：應(yīng)該有可能將所有的運(yùn)行時(shí)構(gòu)件直接與非技術(shù)領(lǐng)域?qū)＜铱梢岳斫獾恼Z言聯(lián)系起來。這對(duì)于直接在業(yè)務(wù)和服務(wù)層公開的抽象非常重要。Sarbanes-Oxley (SOX) 法案是需要這種業(yè)務(wù)可跟蹤性的業(yè)務(wù)驅(qū)動(dòng)程序的一個(gè)例子。 流程：中間相遇 在設(shè)計(jì)取決于現(xiàn)有的 IT 環(huán)境而不是現(xiàn)在和將來的業(yè)務(wù)需要的情況下，自底向上的方法往往會(huì)導(dǎo)致不好的業(yè)務(wù)服務(wù)抽象。而自頂向下的方法可能會(huì)產(chǎn)生不足的非功能性需求特征，并且損害其他的體系結(jié)構(gòu)品質(zhì)因素（例如因域模型中缺乏標(biāo)準(zhǔn)化而導(dǎo)致的性能問題），另外，也會(huì)在服務(wù)和組件中產(chǎn)生不匹配的不良問題。 服務(wù)獲取和知識(shí)代理 應(yīng)該將重用看作是標(biāo)識(shí)和定義服務(wù)最主要的推動(dòng)標(biāo)準(zhǔn)之一。如果組件（或服務(wù)）不可能重用，就不無法將其作為服務(wù)進(jìn)行部署。它可以連接到另一個(gè)與企業(yè)體系結(jié)構(gòu)相關(guān)的服務(wù)，但是不能單獨(dú)作為一個(gè)服務(wù)而存在。 然而，即使從開始就計(jì)劃好了重用，還必須形式化服務(wù)獲取流程。由多個(gè)使用者使用服務(wù)是明確的 SOA 設(shè)計(jì)目標(biāo)。構(gòu)建時(shí)服務(wù)注冊(cè)中心（例如企業(yè) UDDI 目錄）可能能夠解決部分問題。
汽車工作訂單（Automotive Work Order）描述了一家汽車維修公司管理其顧客運(yùn)營(yíng)的流程。我們將通過這個(gè)領(lǐng)域中的問題來闡述 SOAD 的觀點(diǎn)。 工作訂單代表汽車服務(wù)公司和顧客之間的約定，以進(jìn)行一系列例行維修或應(yīng)急維修，例如例行 50,000 英里服務(wù)，更換剎車片或輪胎，或者換油。 業(yè)務(wù)場(chǎng)景（如 圖 7所示）如下：
圖 7. 工作訂單的宏流示例 如果您將此作為一個(gè)獨(dú)立的應(yīng)用程序從頭開始創(chuàng)建，您就可能創(chuàng)建一組如 圖 8所示的類。 圖 8. 工作訂單的類圖示例 如果您將工作訂單構(gòu)造為一個(gè) OO 應(yīng)用程序，這些軟件對(duì)象將包含所有必需的業(yè)務(wù)規(guī)則，并且理解應(yīng)該遵循的業(yè)務(wù)流程。 然而，這種方法在實(shí)踐方面存在著一些缺點(diǎn)：
SOAD 為這些問題提供了極好的解決方案。由于它基于相關(guān)的行為對(duì)服務(wù)進(jìn)行分組，而不是進(jìn)行封裝（行為及數(shù)據(jù)），所以這組服務(wù)與業(yè)務(wù)對(duì)象略有不同。 例如，您可能將工作訂單（Work Order）和工作訂單項(xiàng)（Work Order Item）一起分到工作訂單服務(wù)（Work Order Services），并且創(chuàng)建日程安排（Scheduling）、目錄（Catalog）和庫(kù)存（Inventory）服務(wù)。另外，因?yàn)闆]有服務(wù)實(shí)例，所以沒有與服務(wù)之間的關(guān)系等價(jià)的東西。工作訂單的服務(wù)模型可能看起來如 圖 9所示。 圖 9. 工作訂單的服務(wù)模型示例 與 OO 范式不同，這個(gè)模型并不表示功能系統(tǒng)。既沒有考慮流，也沒有描述業(yè)務(wù)事件或規(guī)則。在 SOA 范式中，在服務(wù)外面維護(hù)的業(yè)務(wù)流程編排決定了執(zhí)行服務(wù)調(diào)用的順序和時(shí)間。 從概念上講，從第一次顧客聯(lián)系到完成工作和帳單支付的整個(gè)業(yè)務(wù)表示單個(gè)宏觀層次的工作單元，并具有數(shù)天到數(shù)周不等的生命周期。畢竟，從企業(yè)的角度來看，工作單元會(huì)產(chǎn)生收入。 然而，實(shí)際出現(xiàn)的情況是在一段相對(duì)長(zhǎng)的時(shí)間內(nèi)單獨(dú)發(fā)生的一系列集中活動(dòng)，例如，定義活動(dòng)、安排預(yù)約、選擇零件和備件、進(jìn)行維修活動(dòng)等等。在 IT 系統(tǒng)中，沒有實(shí)際的 流程會(huì)持續(xù)幾分鐘以上；事件之間的業(yè)務(wù)流程狀態(tài)以數(shù)據(jù)的形式保存在數(shù)據(jù)庫(kù)中。 這種類型的流程可以用狀態(tài)轉(zhuǎn)換模型（例如 UML 中可用的）很好地進(jìn)行表示。 圖 10顯示了用有限狀態(tài)機(jī)（finite-state machine）方法如何對(duì)業(yè)務(wù)流進(jìn)行建模的示例。它是在業(yè)務(wù)流程進(jìn)行時(shí)工作訂單的狀態(tài)如何改變的高級(jí)視圖。 圖 10. 工作訂單的業(yè)務(wù)流程模型 業(yè)務(wù)流程編排集中于狀態(tài)之間的這些轉(zhuǎn)變。單獨(dú)的操作永久地記錄相關(guān)的狀態(tài)改變。 圖 11顯示了部分編排的示例，其中包括 圖 10所示的業(yè)務(wù)場(chǎng)景中的步驟 1 到 5（例如，顧客定義他們的交通工作所需的工作，并且安排預(yù)約以進(jìn)行實(shí)施）。 圖 11. 工作訂單的業(yè)務(wù)交互模型
在本文中，我們已經(jīng)討論和激發(fā)了對(duì)創(chuàng)新的中間相遇的方法的需求，這種方法搭建了業(yè)務(wù)和 IT 之間的橋梁，并且支持 SOA 項(xiàng)目的分析和設(shè)計(jì)階段。我們還提議將這種新的交叉學(xué)科的 SOAD 方法作為一個(gè)整體的建模規(guī)則，它以現(xiàn)在構(gòu)建良好且廣為贊譽(yù)的 OOAD、EA、和 BPM 為基礎(chǔ)。 在詳細(xì)定義 SOAD 表示法和流程的同時(shí)，還確定了關(guān)鍵的原理，比如服務(wù)概念化（或標(biāo)識(shí)）、服務(wù)分類或聚合、策略和方面、中間相遇流程、語義代理和服務(wù)獲取（以供重用）。 SOAD 需要增強(qiáng)現(xiàn)有的軟件開發(fā)方法，進(jìn)一步提高企業(yè)應(yīng)用程序開發(fā)項(xiàng)目的可用性和適用性。隨著時(shí)間的推移，還將發(fā)展相關(guān)的最佳實(shí)踐。 我們還認(rèn)識(shí)到，UML 在流程的表示法選擇方面將繼續(xù)占支配地位；可能需要進(jìn)行增強(qiáng)以滿足更廣泛的 SOAD 的要求。 完成 SOAD 方法的下一步就是定義所需的端到端流程和表示法，復(fù)審活動(dòng)中的角色和它們的責(zé)任，并且繼續(xù)檢查所提議的方法在項(xiàng)目中的有效性。
| ||||||||||||||||||||||||||||||||||||||
聯(lián)系客服
