本節書摘來異步社群《靈活制造——靈活內建基礎結構設計》一書中的第2章，第2.2節，作者：蘇金泷，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視
靈活企業內建基礎結構的模組化之是以有别于傳統模組化，根本原因是其模組化對象和管理思想的改變。傳統模組化的目的是在企業内部對企業進行模組化改造，而靈活企業內建基礎結構的模組化是在企業外部建設靈活化公共服務平台，通過設立一定的接口标準，由外部來規範其成員企業的組織結構。內建基礎結構中的各個子產品，可以分别屬于不同的成員企業，子產品之間既有共性又有個性。內建基礎結構的模組化是根據特定行業的共同經驗，結合特定成員企業自身的情況，來設立虛拟企業的成員企業内部和虛拟企業的整體組織結構模型。是以，系統建構必須建立在充分認識、完整表達和準确分析企業動态聯盟中角色行為的基礎上，也就是說基于網絡的靈活化制造平台的系統模型的優劣是網絡化制造平台能否成功運作的關鍵。可見，如何選擇并改進适應網絡化制造平台的模組化方案顯得至關重要。
內建基礎結構模組化是以靈活制造和靈活供應鍊的成員企業為背景，是以，我們這裡的領域模組化首先是指對靈活企業進行模組化。企業模組化是一個通用的術語，它涉及一組活動、方法和工具，它們被用來建立描述企業不同側面的模型[y07] [l04]；是根據關于模組化企業的知識、以前的模型、企業參考模型，領域的本體論和模型表達語言來完成建立全部或部分企業模型（過程模型、資料模型、資源模型、新的本體等）的一個過程。
如圖2-2所示，內建基礎結構模組化中，體系結構是設計過程的一個階段，它關心的是如何将複雜的系統劃分為主/子系統，以及如何約定子系統的構成和性能。以體系結構為中心的模組化目标[l04]就是建立一個一緻的系統及其部分的視圖集，并以滿足終端使用者和後期設計者需要的結構形式化表達，其中包括需求規劃、規劃設計、綜合模組化、技術支援等多個方面。是以，內建基礎結構軟體體系的建構有兩個特定的廣泛目标。一個外向目标，建立滿足終端使用者要求的系統需求，一個内向目标，建立滿足後期設計者需要以及易于系統實作、維護和擴充的系統部件構成。從建構體系結構，到使用該體系結構實作系統的設計，直到此系統的最終完成和進一步拓展，應包括如下階段[l04]：
1．建立領域模型與本體；
2．根據領域模型與本體，建立系統需求模型。包括基于用況模型的系統需求分析，對用況進行角色模型分析，識别agent；
3．建構選用組織結構模式，并與有關各方進行交流，對此組織（體系）結構進行風險和評價；對agent間的互動進行描述，建立互動協定與互動模型；
4．根據互動模型以及agent結構，建立各個agent進行信念知識庫模型；
5．系統實作，産生代碼模型；
6．實施構造并運作測試。
內建基礎結構模組化過程的各個階段包括[l04]：
1．本體模組化。關于本體的構造，gruber中給出了指導本體構造的5個準則[s06]：（1）明确性和客觀性；（2）一緻性；（3）可擴充性；（4）最小編碼偏差；（5）最小本體承諾。uschold & gruninger提出了一個本體構造的方法學架構，在這個架構内，他們詳細地描述了本體捕獲和形式化的本體設計和評估方法[o03]。m. gruninger & m.s. fox在進行tove本體的研究和開發時，也總結了設計和評估本體的方法學，包括背景和需求描述、非形式化的能力問題描述、詞彙和術語确定、形式化的能力問題描述、用一階謂詞邏輯進行規範描述、确定完整性定理等步驟[fwg01]。bertolazzi等提出了建立核心企業本體（core enterprise ontology，ceo）的方法[go93]。
2．領域模組化。建立領域ontology的關鍵是參照一定的領域模型給出該領域中的概念以及概念之間的關系。在領域工程，領域本體則反映了一個特定領域中可重用的、本質的概念[ukm98]。它提供特定領域的概念定義、概念之間的關系、領域活動、領域理論和原理等，進而描述領域知識。領域知識可以劃分3個層次，領域具體知識、領域概念知識和領域通用（概念）知識。其中領域通用（概念）知識是一種公理化的知識。領域概念知識是領域内本質的知識，即領域本體。領域具體知識是領域内具體事物、具體事件的知識，可以用領域概念知識表達的知識。顯式定義語義資訊的基礎概念已經在分布式問題求解（dps）、agent和知識共享等研究領域建立起來了。xml為這些概念和方法以一種既符合web标準，又符合商業需求的形式重新應用奠定了基礎。這些考慮都直接導緻本體技術應用于xml研究領域。基于xml的本體描述語言有：xol（xml-based ontology language），這是一種基于xml文法和okbc（open knowledge base connectivity）語義的本體交換語言。
3．系統需求模組化。這是在領域模型和本體的指導下進行，充分利用本體描述系統需求，并根據過程模型與本體進行分析。對于大型的軟體開發在很好地了解領域範圍的基礎上建立一個粗略的臨時體系結構輪廓；對系統總目标（戰略目标）進行分析并分解成使用者目标、子目标，用用況描述描述使用者目标或子目标，構造用況模型。然後采用基于角色模型的用況分析，即确定需要哪些角色以及各角色之間如何進行互動去實作用況目标，然後進行角色合并，把角色配置設定給具體的agent即确定系統中的agent。[l04]
4．組織結構模組化。多agent系統（multi agent system，mas）的組織結構與人類的組織模式有着可類比的關系。從宏觀來看，二者都存在任務、資源和資訊的配置設定；從微觀來看，西蒙[gf95]的有限合理性理論表明，二者都要為解決複雜問題而不斷改進組織結構。組織結構模型是系統模組化的核心模型，即系統的軟體體系結構，它包含了系統中最重要的靜态和動态特征[l04]。體系結構是根據企業的需要逐漸發展起來的，受到使用者和其他項目相關人員需求的影響。
5．互動模組化[l04]。本階段主要根據互動模型進行信念知識庫模組化、行為（任務）模組化；根據行為進行互動協定選擇，确定通信的本體以及内容語言格式；分析互動協定制定互動政策，建立效用函數以及約定。理想的互動協定應當存放在協定伺服器上，agent根據互動的需要自動下載下傳協定。如果協定不能滿足互動的需要，我們才會采用圖形工具進行協定規範及模組化。agent在互動過程中應自動實作協定的嵌套以實作複雜的互動（會話）。
面向agent程式設計（agent-oriented programming, aop）已成為軟體開發的主流，它是面向對象程式設計（object-oriented programming, oop）的成功應用。oop中的對象（object）是封裝了狀态和一系列方法的實體，其方法對應于可以對其狀态進行操作的行為，并通過消息激發而被調用以便為其他對象提供服務。傳統的面向對象程式隻有一個控制線程，不足以描述并發性。是以，人們對其進行了改進，進而産生了基于對象的并行計算[pcm01]，建立了活動對象（active object）的思想以描述并發對象，這些對象都有自己的控制線程[kg97]，同時也出現了并發性的程式設計語言，如java。從很多方面來看，agent都與對象很相像，特别是活動對象：它們都封裝了狀态和行為，并通過消息傳遞來通信，都跟程序（process）一樣有自己的控制線程。但是agent決不僅僅是對象的另一個名稱，因為它是一個決策推理系統，它與對象具有不同的任務：agent通過其目标和計劃的驅動而自主運作，它能感覺環境并能對其進行反應；而對象主要是為其他對象提供服務，即便是活動對象，也不具備目标驅動的行為或者叫主動性以及相關的自治性[l04]。而且，oop沒有涉及到協作、競争、協商、計算經濟等問題，而這些卻是形成多agent系統開發的基礎[hx89] [sr91]。
面向agent軟體工程（agent-oriented software engineering, aose）是面向對象軟體工程（object-oriented software engineering, oose）的主要支撐技術，aose分為需求說明、分析、設計和實作等多個階段。其中gaia[wg96]方法吸取面向對象開發的經驗并對oose中的技術進行擴充後用于aose，借用了面向對象的分析和設計的一些術語和符号，試圖采用類似設計社會組織的過程一樣的方法來建構一個mas。其分析階段的目标是獲得由一系列具有某種關系和互相作用的角色（role）而構成的系統組織。角色用4個屬性來進行定義：職責、權利、活動和協定。它和agent間沒有一對一的關系，一個agent可以擔任多種角色。擴充uml的方法：uml是面向對象模組化的事實上的标準。當研究者尋求面向agent 的模組化語言和工具時，他們發現uml是一個顯而易見的開始點，并是以而試圖采用uml的符号來模組化 mas。其中幹得比較出色的是odell和他的同僚們，他們提出了多種擴充uml符号的方法hm98。與此同時，omg和fipa兩個組織也正在緻力于開發基于 uml的符号來支援agent 系統的模組化。
由于采用傳統的面向對象和知識工程的模組化方法缺乏很好地表達主動性、自治性等agent特有的屬性的能力，人們提出了擴充的方法以期全面地對agent系統進行模組化并對 aose做出了較大的貢獻。由于基于知識工程的模組化很少有圖形化的工具，而基于面向對象的模組化大多采用了擴充uml的方法以便進行圖形化表述[l04]。
統一模組化語言（unified modeling language, uml）是面向對象軟體的标準化模組化語言。這是一種由grady booch、jim rumbaugh和 ivar jacobson綜合其booch、omt和oose 方法b99[jvp00]建構的單一标記語言，用于模組化開發的面向對象系統。1997年11月，omg采用uml，并促使其成為業界标準。uml主要用于模組化過程以形成圖形化的文檔，它能夠從不同角度展現系統的動态和靜态行為。
uml提供了用例圖、靜态圖、行為圖、互動圖和實作圖等共5類10種模型圖b99[jvp00]：用例圖（use case diagram）從使用者角度描述系統功能，并指出各功能的操作者；靜态圖描述了系統的靜态結構，包括類圖（class diagram）、對象圖（object diagram）和包圖（package diagram）；行為圖描述系統的動态模型群組成對象間的互動關系，包括狀态圖（state diagram）和活動圖（activity diagram）；互動圖描述對象間的動态互動關系，包括順序圖（sequence diagram）和協作圖（collaboration diagram）；實作圖描述系統的元件關系和實體裝置的配置關系，包括元件圖（component diagram）和配置圖（deployment diagram）。uml并沒有涵蓋所有領域的不同的概念，而是提供了一種擴充機制以便定義符合各自領域的更為精确和清晰的模型。它提供了标記值、限制和版類3種方法，對模型元素的性質、規則限制及語義進行擴充。
模型是建立系統的基礎。模型與系統的關系主要展現在宏觀與微觀兩個層面上。系統在宏觀上可以了解為一個模型，系統的建立過程就是以計算機為基礎的模型的建立過程；系統在微觀上是由一系列模型構成的有序集合。
內建基礎結構模組化是在內建基礎結構理論的基礎上，建構高層即應用層的體系結構。是以，以體系結構為中心的內建基礎結構模組化有兩層含義[l04]：（1）充分考慮內建基礎結構提供的體系結構模式（包括agent 群體結構以及個體結構模式），根據系統要求，選擇合适的體系結構模式，并按照具體的結構模型去建構實際模型；（2）模組化過程中所建立的各種模型是對系統不同視圖的描述，它們的組合構成了應用層的體系結構，可以解決需求與實作之間的差距。
內建基礎結構模組化中采用體系結構為中心的模組化步驟、面向對象的mas模組化思想、uml統一模組化工具，針對內建基礎結構的具體特點，建構出一系列的模型。其中，功能上包括：供應鍊的過程模型、資料通路模型、生産制造的流程模型、企業資源模型、決策和博弈模型等等；建構過程包括：系統需求模型、組織模型、互動模型、個體模型、代碼模型、實作模型等等。構造模型的基本技術手段是抽象，同一個事物可以有不同的抽象，如何選擇取決于構造它的目的。
靈活企業的內建基礎結構模組化是以agent為關鍵抽象機制，以産品/服務為中心通過agent對企業經營過程進行描述，同時建立一個通用的、可重用的企業知識本體表示，通過跨行業跨企業的通信與資訊處理來支援企業間的合作博弈，為內建基礎結構中的靈活供應鍊和基于網絡的靈活化制造創造條件。企業模組化要支援靈活制造企業工程與基礎，能夠通過模組化分析、優化、流程重組、模型改進、轉向資訊系統需求分析與設計、實作等一系列連續的螺旋式的上升的過程，有助于企業業務過程的不斷改進與優化，支援靈活資訊系統的快速、成功建設及評價與改進的過程[l04]。
來看靈活供應鍊中采購過程模組化示例：圖2-3、圖2-4和圖2-5所示為靈活企業的內建基礎結構中企業采購過程的部分uml模組化示圖。其中，圖2-4所示是基于面向對象的mas模組化思想的采購過程需求模型，對采購過程中的各個agent角色模型進行分析，研究各個agent之間的關系。圖2-5所示從體系結構模組化的角度來看是一個領域模型，該階段評估了系統的體系結構，分析了各個角色的資訊流向和互動協定，确定功能分塊和每一個功能塊主要任務。圖2-6所示則是互動模型，它确定采購過程中通信的本體以及内容語言格式等，分析互動協定制定互動政策，分析每一個程序的生命周期。
靈活制造中工作流模組化示例：工作流過程具有典型的生命周期特性，根據過程的複雜性及其所含内容的不同，它可以僅僅維持幾分鐘，也可以長達幾天甚至幾個月；它在不同的周期過程具有不同屬性[l04]。如同作業系統中的程序的概念，在工作流管理系統中，工作流可以被抽象為一個狀态機fsm(finite state machine)，由于系統中各種内外部事件的發生，或者由于工作流引擎執行特定的操作，使得工作流執行個體狀态不斷改變[l04]。
dao資料模型示例：dao資料通路對象模式将資料通路邏輯抽象為特殊的資源，将系統資源的接口從其底層通路機制中隔離出來，通過将資料通路的調用打包，促進對于不同資料庫類型和模式的資料通路。資料通路對象實際上就是包含對于所有資料通路邏輯的對象，并管理着對于資料源的連接配接，根據資料源的不同，資料通路對象實作了不同的通路機制。資料通路對象将資料源的實體實作細節與其使用者完全分離開來，并且在底層資料源變化的時候，資料通路對象向使用者提供的接口是不會變化的。這種方法使應用系統使用資料通路對象時可以适應多種資料存儲媒體，在這裡資料通路對象就是系統元件和資料源中間的擴充卡。[bq02] [bh02] [erh03] [pcqy03]
在圖2-7所示的序列圖中，業務對象（business object）表示使用資料的用戶端，一個業務對象可以用會話bean、實體bean或是其他java程式來實作。資料通路對象（data access object）是這種模式中的主體，它是底層資料通路的對象，并将其提供給業務對象以使得後者能夠透明地通路資料源。同時業務對象也将資料的加載和存儲操作移交給資料通路對象處理。資料源（data source）可以是一個資料庫，包括關系型資料庫、面向對象資料庫或檔案系統。傳輸對象（transfer object）指的是資料載體，資料通路對象可以使用傳輸對象來向使用者傳回資料，而資料通路對象同樣可以從使用者那裡得到傳輸對象來對資料源中的資料進行更新。該模式具有良好的透明性、高可移植性、低複雜性、高可操作性。在該模式下，由于資料通路細節被資料通路對象隐藏，業務對象可以在不了解資料源實作細節的情況下通路資料，形成一種“透明”通路過程；由于業務對象與資料實作是隔離的，是以在移植過程中，僅需對資料通路對象進行一些變化即可，是以可以友善地在應用系統中添加通路對象，表現出高可移植性；由于資料通路對象可以管理所有的資料通路複雜細節簡化了業務子產品和其他資料客戶的代碼，系統整體上具有較高的可讀性、高開發率，即代碼具有低複雜性；該模式下系統所有資料通路操作都移交給資料通路對象，簡化了相關操作bq02erh03。該模式的不足表現為：如果ejb容器采取容器管理的方式，那麼所有對于持久性資料存儲的管理都由容器負責，則意味着資料通路對象在資料使用者和資料源之間添加了一個層面，增加了一些額外的設計和實作的負擔bq02erh03。