解讀IEEE 7417的軟件體系架構描述的概念模型

本文將解讀標準IEEE Std 1471-2000（密集型軟件的體系結構描述推薦實施規程）的概念模型圖部分，從中一窺做爲軟件架構師的進行架構設計的思考角度與策略。若是咱們把世界當作一場遊戲，如今要玩的就是策略遊戲而已。

 

說明：

IEEE 1471是適用於軟件密集的系統，其目標在於：便於體系結構的表達與交流，並經過體系結構要素及其實踐標準化，奠基質量與成本的基礎。

細讀這個標準，能夠增強策略遊戲的裝備，全新上戰場。

 

基本概念

IT框架的設計者必須是傑出的問題驅動者，設計每每是一個模糊的，非理性的過程，基本概念掌握後，至關於準備好攻擊的工具了。

什麼是密集型系統呢？1471中的框架標準，主要是針對密集型系統（software-intensive 也稱做加強型軟件），是指軟件對於整個系統的設計、構建、部署和評估有重要影響的任何系統。

除了軟件體系架構描述的概念貫穿標準始末，還有兩個概念：視圖（view）和視點（viewpoint），是在整個框架中將大量會使用到。

視圖：是指從相關的關注點的角度來看整個系統的表示。

視點：則是構造和使用視圖的約定規範。是一種模式和模板。

他們的關係是：view是表達系統架構在viewpoint中所定義的關注點的表達，而viewpoint是定義了一種語言或方法來描述這些view。他們就相似viewpoint探照燈和人們經過探照燈點亮而看到的view。

 

至於System StakeHolder（SH 利益相關者）、Architectural Description（AD 架構描述）、Acquirer（需方）、Concern（關注點）這樣的概念會穿插在概念模型中介紹。

AD架構描述：是指一組用於記錄體系結構的產品，如文檔集等。

Acquirer：一個從供方那裏採購系統、軟件產品或軟件服務的組織。（需方能夠是買家、客戶、全部者、用戶或購買者）

 

軟件體系架構概念模型

咱們說，架構定義階段通常在軟件生命週期中，位於需求分析和設計階段之間。在這個階段要考慮到利益以及涉及利益者的利害關係，由此來造成一個均衡的解決方案。

下圖是IEEE Std 1471標準的核心，是一張用UML來表達體系架構要素之間關係的一張重要圖示，讀懂了這張圖，做爲架構師將具備有居高臨下的大覽之心。只要會UML語言，咱們就能夠很輕鬆的來解讀它。

該圖將要素以分層的方式，關聯和聚合的概念，表述體系結構中不一樣要素之間的重要關係。讓咱們來一一分解。

第1層：Mission（任務）

系統的存在是爲了在某種環境裏履行1個或多個任務。一個任務（mission）是指一種使用或操做，是一個系統想要知足由一個或多名利益相關者的目標。如圖所示Mission只關聯System，所以其實框架的起點能夠看做是下一層的System。

第2層： Environment、System、Architecture

是從System開始的。這裏的系統是個廣義的統稱，包含：應用程序、傳統意義的系統、子系統、系統的系統、產品線、產品組、整個企業或其餘利益集團等。

任何一個System都是在某個環境（Environment）中的，而環境又影響（influences）着系統，由於環境，有時候是指上下文（context），決定了這個系統的發展、運做、政治和其餘影響的設置和情形。環境也會直接或者間接的影響與之交互的其餘系統。環境能夠肯定一個系統的邊界以及與其統的交互範圍。也就是能夠在本系統和與之相關的其餘系統之間畫一條線，這個線就是邊界。

系統有（has an）一個架構。一個架構能夠由一個架構描述來記錄。

這裏的系統和架構雖然是一對一的關係，可是仍是有區別的，一個是概念上的是一個實際具體的事物。

 

第3層：Stakeholder、AD、Rational

1個系統擁有1個或多個利益相關者。利益相關者擁有1個或多個關注點。

關注點是指對於那些操做或其餘方面對於一個或多個利益相關者很是重要，且與那些系統發展相關的利益。

一般關注點包括系統的功能要求、性能需求、安全性、可靠性和保密性等。

架構描述是由多個view組合而成的。體系架構描述將1個或多個模型聚合到視圖中。

架構描述選擇一個或多個視點供使用。這種選擇依賴於利益相關者關注點須要經過架構描述來解決。

例如，ISO的（RM-ODP 開放式分佈處理的參考模型）所選擇5個視點。可是IEEE std 1471-2000中沒有說起選擇的特定的視點。能夠用架構描述來定義一個視點，也能夠在其餘地方定義在架構描述中使用而已。

架構描述定義1個或多個利益相關者的關注點。

AD須要提供基本原理，也就是AD須要提供選擇當前架構的緣由，架構設計師如何知足功能性與非功能性需求的。

 

​第4層：Concern，Viewpoint，View

每個view又涵蓋了一個或多個利益相關者的關注點。一個視圖是根據視點（viewpoint）中定義的規則和約定所建立的。除了視圖中描述的信息以外，一個架構的描述還能夠包含其餘的信息，例如系統概述和系統原理等。這些信息的來源可能不是某個視點，而是遵循了其餘組織文檔的實踐。

一個視點是經過建立、描述和分析視圖而創建的一種約定。也就是說，一個視圖聽從一個視點，一個視點決定了描述視圖的語言（包括符號、模型或產品類型），任何一種相關的建模方法或者分析技術，都將被應用在視圖的表述上。

 

第5層：Library Viewpoint，Model

外部定義的視點被稱做視點庫，例如RM-ODP中的那5個視點。

1.  企業視點（Enterprise Viewpoint）：分析系統目的、商業需求、策略和系統範圍的試點。處理與企業層面有關的信息，例如組織結構和政策等。

2.  信息視點（Information Viewpoint）：信息的結構，當中包括信息的變化、流程及不一樣功能上的邏輯分割。

3.  計算視點（Computational Viewpoint）：着重於系統的分解成相對的實體及接口。

4. 工程視點（Engineering  Viewpoint）：處理有關分佈式系統對象間的交互（interaction），及描述如何支持有關的交互。

5. 技術視點（Technology Viewpoint）：定義有關係的軟件及硬件組件。

 

 

一個視圖可能由1個或多個模型組成，模型能夠參與一個或多個視圖。

每一個這樣的模型都是根據對應觀點定義中創建的方法來定義的。

 

 

換個角度來理解就是：

• 任何一個系統(System)是爲了達成某些利益相關者(Stakeholder)的某些人物(Mission)，在特定環境(Enviroment)中構建的。每個系統都有一個架構(Architecture)。

• 架構(Architecture)是對全部利益相關者的關注點(Concern)的響應和回答，經過架構描述(Architecture Description)來講明。每個利益相關人都有各自的關注點。這些關注點是指對其重要的，與系統的開發、運營或其它方面相關的利益。

• 架構描述(Architecture Description)本質上是多視圖的。每個視圖(View)是從一個特定的視點(Viewpoint)來表述架構的某一個獨立的方面。試圖用一個單一的視圖來覆蓋全部的關注點固然是最好的，但實際上這種表述方式將很難理解。

• 視點(Viewpoint)的選擇，基於要解決哪些利益相關人的哪些關注點。它決定了用來建立視圖的語言、符號和模型等，以及任何與建立視圖相關的建模方法或者分析技術。

• 一個視圖(View)包括一個或者多個架構模型(Model)，一個模型也可能參與多個視圖。模型較文本的表述的好處在於，能夠更容易的可視化、檢查、分析、管理和集成。

 

架構設計有助於系統從最初概念產生到退役的開發、操做和維護的整個生命週期的工做。所以在軟件開發中加入架構設計概念後，能夠幫助在軟件開發中對軟件上下文的理解，總體環境和系統的認知，而不只僅是多增長了一個活動而已。

 

參考文獻：

1. http://www.rm-odp.net

2. http://blog.sina.com.cn/s/blog_5a010cd10100xxiz.html

3. Summary of IEEE 1471 By Jan Øyvind Aagedal, SINTEF Telecom and Informatics