企業架構研究總結（43）——企業架構與建模之ArchiMate詳述（下）

2.7 關係模型元素

      企業架構模型包括了各類概念元素以及他們之間的關係，這其中的概念元素已經在前面幾節中進行了闡述，而這些概念元素之間的關係則是本節的敘述重點。雖然ArchiMate中具備種類繁多的概念元素，而且橫跨企業中的多個領域，可是這些元素之間的關係通過抽象後卻並不像想象中那麼多，而且其中的大部分關係來源於諸如UML、BPMN等在業界被普遍使用的標準，於是掌握起來並不難。整體來講，ArchiMate中的關係元素可歸納爲以下三類：

• 結構關係：用於表示相同或不一樣類型的概念元素間結構的關係。
• 行爲關係：用於表示行爲元素之間的依賴關係。
• 其餘類型關係：不屬於以上兩種類型的關係。

2.7.1 結構關係

      結構關係有着強弱之分，這一點在經過關係鏈合併（即兩個概念元素間若是沒有直接關係鏈接，可是卻能夠經過一系列結構關係而間接相連，則他們之間可看做爲具備一條間接結構關係，且此間接關係與關係鏈中關係強度最弱的結構關係相同）而獲取概念元素之間的間接關係時尤其重要。本節將按照從強到弱的順序對這些結構關係一一進行描述。

 

2.7.1.1 組合關係（Composition Relationship）

• 定義：用於表示一個對象是由其餘若干組件組合而成。組合關係來源於UML，於是與一樣來源於UML的聚合關係（Aggregation）相比，雖然二者都表示了包含與被包含的關係，但具備組合關係的容器對象和組件對象具備更強的聯繫：一個對象能且只能做爲一個組成部分而被組合到一個容器對象之中。
• 表示圖符：

• 實例：在本案例中，「財務應用」包含了三個子組件，分別爲：「會計組件」、「計費組件」和「支付組件」。

 

2.7.1.2 聚合關係（Aggregation Relationship）

• 定義：用於表示一個對象組織包含了其餘若干對象。與組合關係相似，聚合關係也來源於UML。不過與組合關係不一樣的是，聚合關係沒有那麼強的約束關係，即一個對象能夠經過聚合關係而從屬於兩個或兩個以上的容器對象。
• 表示圖符：

• 實例：在本案例中，「車輛保險」這一產品包含了「更改條件」和「提交索賠」這兩個業務服務，但這兩個業務服務並不會由於該產品的退出而消失，亦即具備不一樣的生命週期。

 

2.7.1.3 分配關係（Assignment Relationship）

• 定義：分配關係用於在主動性結構元素（業務角色或應用組件等）和表示其行爲的行爲元素之間，或在業務參與者與其所扮演的業務角色之間建立聯繫。
• 表示圖符：

• 實例：本案例描述了兩種分配關係：其一是「支付接口」與「支付服務」之間的支配關係，他表示了須要經過「支付接口」來獲取「支付服務」；另一個是「財務應用」與「支付功能」之間的支配關係，他表示了「財務應用」這一主動性結構元素可以執行「支付功能」這一行爲。

 

2.7.1.4 實現關係（Realization Relationship）

• 定義：實現關係用於將邏輯實體與用於實現他的更加具體的實體鏈接在一塊兒，從而體現二者之間的實現與被實現關係。實現關係能夠存在於運行的情景之下（例如，業務流程或業務功能實現業務服務），也能夠存在於設計-實現這一情景中（例如，數據對象實現業務對象，或製品實現應用組件）。在ArchiMate 2.0的動機擴展中，實現關係的意義有所拓寬，由於在此擴展中僅有邏輯概念，而並不像核心元素中那樣具備從邏輯到現實的跨越，因此在這一擴展中，實現關係除了具備原來的邏輯到現實這一方向外，還具有了僅在邏輯維度上逐步細化方向。動機擴展爲實現關係的使用增長了以下三個方面的情境：
• 目標可被原則、需求或約束所實現。
• 原則可被需求或約束所實現。
• 需求可被用於表示具體系統的概念元素所實現。
• 表示圖符：

• 實例：本案例展現了實現關係所適用的兩種情景：從運行角度來講，「財務應用」這一應用組件實現了「計費服務」；從設計-實現這個角度來講，數據對象「計費數據」實現了業務數據「單據」。

 

2.7.1.5 使用關係（Use by Relationship）

• 定義：使用關係被用來描述流程、功能或交互對於服務的使用，以及業務角色、應用組件或合做集合對各種接口的訪問。從其表示圖符來看，使用關係借用了UML中依賴關係的表示圖符，不過二者的含義卻不盡相同。
• 表示圖符：

• 實例：在本案例中，名爲「更新客戶信息服務」的應用服務被「變動地址流程」這一業務流程所使用，而隸屬於「客戶關係管理系統」的「客戶關係管理接口」則被業務角色「前臺職員」所使用。

 

2.7.1.6 訪問關係（Access Relationship）

• 定義：用於描述行爲元素對業務或數據對象的訪問。訪問關係具備方向性，其圖符連線上的箭頭指示了信息流動的方向（若是箭頭指向業務或數據對象，則表示行爲元素對其執行寫操做，反之則表示行爲元素對業務或數據對象執行讀操做），而若是圖符沒有箭頭指向則表示行爲元素與業務或數據對象之間同時具備讀和寫的關係。
• 表示圖符：

• 實例：在本案例中，「建立發票」業務流程建立了業務對象「發票」，而業務流程「發送發票」則對此業務對象執行了讀取操做。

 

2.7.1.7 影響關係（Influence Relationship）

• 定義：影響關係描述了某些動機元素對其餘動機元素具備正面或負面的影響。影響關係反映了現實中在決策階段須要進行權衡利弊的情景，處在這條關係兩端的元素並無很強的依賴或實現關係，於是並不能由於影響源元素對受影響的元素有正面影響就把其看成實現受影響元素的必要條件，一樣也不能由於影響源元素對受影響的元素有負面影響就在受影響元素的實現之中將其排除。
• 表示圖符：

• 實例：本案例展現了用來實現「提升產品組合管理」這一目標的兩個需求所產生的利弊權衡情形。對於「指派我的助理」這一需求來講，他對「下降人員工做量」這一目標有着負面影響（二者之間的影響關係標註了兩個「-」），但他對「改善客戶滿意度」卻有着很是正面的影響（影響關係被標註了兩個「+」），同理可知，此需求對於「系統必須面客戶」這一原則也有着很是負面的影響。

 

2.7.1.8 關聯關係（Association Relationship）

• 定義：用於描述對象之間不一樣於以上各類特定關係的聯繫。關聯關係來源於UML，於是與其所定義的同樣，主要用來描述業務或數據對象之間不屬於組合、聚合以及特化（繼承）的關係。除此以外，在ArchiMate中關聯關係還主要用來聯繫信息元素與其餘種類的元素，例如業務對象與表現方式、表現方式與含義等。
• 表示圖符：

• 實例：在本案例中，業務對象「保險政策」在「客戶」和「參保對象」這兩個業務對象之間具備關聯關係，而且「保險銷售服務」與「受保」這一價值元素之間也有着關聯關係。

 

2.7.2 行爲關係

2.7.2.1 觸發關係（Triggering Relationship）

• 定義：用於表示流程、功能、交互或事件之間的時序或因果關係。
• 表示圖符：

• 實例：本案例描述了從「保險申請」事件觸發「接收申請」業務流程開始到「申請批准」事件的產生爲結束的整個過程。

 

2.7.2.2 流動關係（Flow Relationship）

• 定義：用於描述流程、功能、交互或事件之間對信息或價值的交換或轉移。
• 表示圖符：

• 實例：在本案例中，業務功能「日程安排」將索賠訴求的處理安排信息傳遞給業務功能「索賠評估」，然後者最後會將評估結果轉移給「理賠」這一業務功能，從而進行對於索賠訴求的最終處理。

 

2.7.3 其餘類型關係

2.7.3.1 分組關係（Grouping）

• 定義：用於根據一系列對象的通用性質來對他們進行分類組織。分組關係與UML中的「包」概念相相似，他們均可用來對各類對象進行分類組織。與組合和聚合關係不一樣，分組關係中並無一個容器性對象，全部對象都被平等地組織在一塊兒。
• 表示圖符：

• 實例：在原本中，「財務管理」分組中包含了此領域中的相關業務對象：「單據數據」、「帳戶信息」和「債務信息」。

 

 

2.7.3.2 鏈接關係（Junction）

• 定義：用於鏈接相同類型的行爲關係。
• 表示圖符：

• 實例：在本案例中，「訪問申請」業務流程以後經過鏈接關係對該業務流程以後可能出現的兩種狀況進行了描述：若是申請被接受，則進入「通知接受申請」業務流程；若是申請被否決，則進入「通知拒絕申請」業務流程。因而可知，本案例中的鏈接關係描述了流程之間邏輯或的關係，但這並不表明鏈接關係只能表示這一種邏輯關係，建模人員甚至能夠經過ArchiMate擴展規則對鏈接關係進行特化，從而可以清楚地表達各類邏輯關係。

 

2.7.3.3 特化關係（Specialization Relationship）

• 定義：用於表示一個對象是另一個對象的特殊化對象。此關係來源於UML的特化（繼承）關係，但在ArchiMate中此關係所涉及的概念元素卻不只僅是業務或數據對象。任何一個概念元素的實例都可爲同類型概念元素的其餘實例的特化。
• 表示圖符：

• 實例：從本案例中能夠看出，業務流程「處理旅遊保險」和「處理行李保險」都是業務流程「處理保險」的具體特化。

 

2.8 ArchiMate擴展機制

      經過前面幾節的介紹，咱們對ArchiMate 2.0中定義的概念元素以及他們之間的關係有了應該有了必定的瞭解，但這並不表明這些元素和關係就足夠應對一切狀況，於是基於以下的緣由，ArchiMate須要有必定的擴展機制來應對現實使用過程所面對的具體問題：

• 因爲ArchiMate面向的是企業架構模型，且此種模型的抽象層次較高，於是在實際使用過程當中必定會遇到ArchiMate標準所沒有精肯定義的狀況。因此ArchiMate須要經過擴展來應對具體領域中的問題。
• 企業中可能已經存在了大量的具體領域內的模型，而企業架構模型也只是在抽象層次上與這些具體領域模型的描述內容有所區別，但因爲他們都是對「企業」這一客觀對象進行建模，因此他們之間應該是相互融合，而不是相互割裂的。爲了達到這種融合，採用ArchiMate所創建的模型須要通過擴展來兼容各具體領域模型。
• 模型的重要目標之一就是輔助分析決策，雖然ArchiMate在不一樣領域之間創建了聯繫，但缺少足夠的細節來支持針對具體領域模型的分析方法。
• 模型的重要目標還包括促成干係人之間的無障礙溝通，但因爲不一樣領域、不一樣背景的干係人其使用的溝通語言也不盡相同，於是只有經過擴展ArchiMate才能幫助干係人之間的溝通。

      因而可知，ArchiMate語言是一種核心語言，須要經過擴展來聯繫本來分離的具體領域內的模型，於是咱們不能把他當作諸如UML這樣的一應俱全的語言。實際上，ArchiMate的初衷也並非要從頭創建一種新的語言（那樣只會帶來新的學習曲線以及由此產生的抵制），而是對各類領域標準和最佳實踐進行抽象後獲得共通的部分，並以面向服務架構（SOA）概念爲基礎，將抽象出的各領域的通用聯繫起來，最後輔以擴展機制來適應各類具體狀況。這一語言擴展規則能夠總結爲以下兩點：

• 增長屬性：前面介紹的各類概念元素只給出其定義而並無設置其屬性，於是建模人員能夠根據須要爲各類概念元素添加適當的屬性。例如，若是要對企業進行性能分析，就須要爲各個概念元素添加諸如服務時間、吞吐量這樣的屬性。因爲屬性的添加具備必定的背景性，即爲了避免同的目的所添加的屬性也不盡相同，而概念元素卻具備更強的穩定性，於是保證概念元素與屬性的獨立性是必要的。爲了解決這一問題，ArchiMate擴展規則建議採用屬性配置的方式來記錄概念元素和特定屬性的對應關係，而且這一映射配置的存儲將獨立於模型的存儲。
• 進行特化：因爲ArchiMate中的概念元素都是由各領域建模語言以及最佳實踐抽象而來，於是也能夠經過特化（繼承）的方式將其轉換回去，從而將各領域內特有的概念元素添加到ArchiMate之中。ArchiMate 2.0中列舉了以下實例：

 

2.9 跨領域關聯

      經過前面對於概念元素以及他們之間的關係的介紹，咱們能夠在高抽象層次上建立企業架構模型，並能夠經過擴展機制來適應實際應用過程當中遇到的各類問題，不過ArchiMate所不一樣於具體領域內建模語言的根本仍是在於它能將各個分立的領域聯繫起來，從而創建具備一致性的模型。前面已經提到過，在ArchiMate中跨領域的聯繫的基礎是面向服務架構（SOA），不過爲了達成業務與信息技術之間的協調整合，一般來說，還須要注意其餘的概念元素間關係，而本節將針對這些跨領域關聯的經常使用模式進行概括總結。

2.9.1 業務-信息技術協調整合

      在上圖中，包含在「業務層」分組以內的是具備跨領域關聯關係的各個業務領域概念元素，而分組以外的則是與之相關的信息技術領域（應用層和技術層）內的概念元素。如圖所示，業務與信息技術之間的跨領域關聯關係主要包括了以下幾個方面的內容：

• 使用關係：業務行爲元素（業務流程、功能、交互）可使用應用服務，而業務參與者和業務角色除了可使用應用服務外還能夠對應用接口進行使用。
• 實現關係：數據對象與業務對象之間具備實現關係，而這條關係說明了數據對象是相關業務對象的一個電子化表現方式。
• 分配關係：
• 應用組件與業務流程、功能、交互和服務之間具備分配關係，用以體現業務行爲元素是在應用組件支持下的自動化行爲，而對於非自動化行爲來講，各行爲元素和應用組件之間應該採用使用關係。須要注意的是，ArchiMate 2.0中對於涉及到分配關係的跨領域關聯的描述中還包括了應用接口和業務服務之間的關係，不過就筆者的理解來講這條關係應該不是一條直接關係，而是將相關關係鏈（應用接口與應用組件之間具備組合關係，而應用組件能夠經過分配關係關聯到業務服務，而在這條關係鏈中因爲分配關係優先級最低，於是應用組件和業務服務之間具備間接的分配關係）進行轉換而得的間接關係，由於應用接口是應用組件對外提供服務的渠道，同時也是應用組件的一個組成部分，於是對於經過應用接口使用應用服務的業務服務或其餘業務行爲元素來講，將應用接口直接「分配」給他們是有待商榷的。
• 應用組件與位置之間的分配關係指明瞭應用組件的空間位置。
• 與前一點相相似，數據對象與位置之間的分配關係亦指明瞭數據對象，這個業務對象的電子化表現方式，在空間中的位置。
• 技術層各概念元素中的節點、網絡、通訊路徑和製品與位置之間也具備分配關係，分別用以表示他們在空間中的位置。
• 聚合關係：產品和應用服務之間具備聚合關係，這說明應用服務能夠做爲產品的一個部分而直接提供給客戶。同理，處於技術層中的基礎設施服務也能夠經過聚合關係而成爲產品的一個組成部分。

 

2.9.2 應用-技術協調整合

      上圖展現了應用層和技術層之間發生跨領域關聯的各類概念元素，以及他們之間的關係。這些關係主要包括以下幾個方面的內容：

• 使用關係：
• 應用組件和應用功能可使用技術層面的基礎設施服務。
• 應用組件可使用技術層面的基礎設施接口。
• 實現關係：
• 數據對象與製品之間的實現關係體現了邏輯上的數據對象與物理上的存儲或部署對象之間的關係。例如，數據對象能夠存儲在一份數據文件之中。
• 同理，應用組件和製品之間的實現關係也體現了邏輯上的應用或應用組件與物理上的可執行程序文件之間的關係。

 

2.9.3 動機擴展-核心協調整合

      動機擴展的目標是對採用核心概念元素所建模型的緣由進行描述，於是這一擴展所包含的各個概念元素與核心概念元素之間有着密不可分的關聯。須要注意的是，ArchiMate 2.0（第10.4節Cross-Aspect Dependencies）已經明確指出：動機擴展中僅有需求和約束元素能夠經過實現關係與核心概念元素髮生直接關聯，不過在其中的圖72（本文中的圖 203）中又爲動機擴展元素與價值概念元素之間添加了一條影響關係，因爲影響關係的定義只涉及到在動機概念元素之間描述權衡利弊的狀況，於是其圖72種所描繪的動機擴展元素與價值概念元素之間的影響關係不該該是一條間接關係（雖然二者之間能夠經過關係鏈相連，不過按照合併規則最後得到的應該是關聯關係而不是影響關係），而應該是一條直接關係。此外， 干係人與業務參與者之間的分配關係也應該是直接關係。所以，筆者認爲上圖中所表示的各條關係中，直接關係包括了需求、約束和核心概念元素之間實現關係、各動機擴展概念元素與價值之間的影響關係，以及干係人與業務參與者之間的分配關係。動機擴展與核心元素之間的關聯關係主要包括以下內容：

• 影響關係：各個主要的動機概念元素（驅動力、評估、目標、原則、需求和約束）與業務層的概念元素「價值」之間具備影響關係，亦即這些表述建模動機的概念元素對於業務價值有着正面的或負面的影響，從而體現了不一樣動機之間的權衡關係。
• 實現關係：絕大部分核心概念元素（除了含義和價值等概念元素）能夠實現動機擴展中的需求和約束這兩個概念元素。須要注意的是，因爲需求概念元素與價值概念元素之間有着影響關係，於是根據關係合併規則，那些用來實現需求和約束的核心概念元素與價值概念元素之間有着間接的影響關係。
• 分配關係：干係人概念元素所指代的是對架構產生的結果具備利益關係或對其進行關注的我的、團隊或組織的類別，其並不特指某個特定的參與者個體或組織，因此爲了體現他們之間的關聯就須要經過分配關係將他們聯繫起來，而這與業務角色和業務參與者之間的分配關係也是類似的。
• 關聯關係：干係人與價值和含義之間分別具備一條關聯關係，不過從前面的敘述中咱們可知，這兩條關聯關係應該是經過合併關係鏈而得的間接關係，而不是直接關係。不過從關聯關係的定義來看，他們之間創建直接的關聯關係也無不可，於是須要根據建模實際狀況來進行判別。

 

2.9.4 實施和遷移擴展-核心協調整合

      實施和遷移擴展的目標是對企業架構從設計走向實現的這一過程進行建模，於是其所包含的各類概念元素與核心概念元素之間也有着密不可分的關係，這些關係的主要內容包括：

• 分配關係：
• 業務角色與工做包之間具備分配關係，用以表示參與到工做包實施中的我的或團隊所擔負的職責。
• 位置與交付物、工做包之間具備分配關係，用以表示他們在空間中的位置。
• 聚合關係：穩定階段描述了架構在必定期間內的狀態，而爲了對此穩定階段包括了哪些架構的部分進行描述，咱們須要經過聚合關係來聯繫穩定階段與相關的核心概念元素。
• 關聯關係：差距用於描述兩個穩定階段之間發生變化的架構部分，於是須要經過關聯關係來對差距和表明了發生變化的架構部分的核心概念元素建立聯繫。
• 實現關係：交付物與絕大部分概念元素之間具備實現關係。

 

2.9.5 實施和遷移擴展-動機擴展協調整合

      嚴格來講，實施和遷移擴展與動機擴展之間並無直接的關聯，而都是經過經由核心概念元素的關係鏈而進行關聯。例如，交付物能夠實現諸如應用組件、業務流程這樣的核心元素，然後者又能夠用來對動機擴展中的目標或需求進行實現。不過在實際建模過程當中，在這兩個擴展之間建立直接關聯也有助於更加清晰地體現企業架構實現與動機之間的關係，且也符合ArchiMate的基本語法。這兩種擴展之間的關係可總結以下：

• 聚合關係：因爲對於架構的需求或目標都有其自身的生命週期，於是某一個具體需求或目標可能僅適用於某個穩定階段，而另外的需求或目標則屬於其餘的穩定階段。爲了體現這種關係，穩定階段概念元素能夠聚合相關的需求或目標概念元素。
• 實現關係：從前面的例子能夠看出，交付物概念元素與需求概念元素之間有着實現與被實現的關係，於是他們之間能夠經過實現關係相聯繫。