軟件架構的視角，視點及利益相關者
系統(tǒng)必然是復雜的，如何清晰準備的描述一個系統(tǒng)，是架構工作的困難之處。有兩個架構觀點，雖然各有側重，但是殊途同歸，都是軟件架構的基本方法。需要注意的是，這兩個架構觀點對視圖的定義和理解略有不同，視點應該就是視圖。
“4+1”視圖模型
面對復雜和不確定的業(yè)務需求，為了避免盲人摸象的局面，使用視圖和視點的方法是比較有效的。Philippe Kruchten在他的文章《Architectural Blueprints—The “4+1” ViewModel of Software Architecture》詳細介紹“4+1”視圖模型。在這個模型中，視圖是指從不同的利益相關者的角度來描述系統(tǒng)，利益相關者可以是最終用戶，開發(fā)者，也可以是項目經(jīng)理。由此，4個視圖就分別是邏輯視圖，開發(fā)視圖，進程視圖和物理視圖。另外“+1”的視圖是選擇一些用例和場景來描述架構。
開發(fā)視圖：開發(fā)視圖是從程序員，以及軟件管理的角度來描述系統(tǒng)。這個視圖也被稱為實現(xiàn)視圖，往往使用UML組件圖來描述系統(tǒng)構成。
邏輯視圖：邏輯視圖主要描述系統(tǒng)為最終用戶提供的功能。一般對應于UML工具的類圖，狀態(tài)圖等。
物理視圖：物理視圖是從一個系統(tǒng)工程師的角度來描述系統(tǒng)。這個視圖關切軟件組件在物理層拓撲結構以及組件之間的物理連接，通常也被稱為部署視圖。UML工具中稱為部署圖。
進程視圖：進程視圖處理系統(tǒng)的動態(tài)方面，比如系統(tǒng)的進程之間如何通信以及運行時的行為，比如并發(fā)，分布式，集成，性能，擴展性等。UML工具用活動圖來表示。
場景視圖：場景視圖使用一些用例或者場景來描述進程和對象之間的交互，并且用來驗證架構設計，也是架構原型的測試起點。
使用視點和視角與利益相關者合作
使用視點和視角與利益相關者合作的觀點是由NickRozanski 和 Eoin Woods在《軟件系統(tǒng)架構:使用視點和視角與利益相關者合作(原書第2版)》一書中闡述的。如果說有哪本書可以作為軟件架構的教科書的話，那么非此書莫屬。什么是架構?為什么架構在工作中至關重要?如何確定架構的利益相關者以及他們的關切?如何在實現(xiàn)和需求之間尋找平衡?如何和利益相關者溝通你的架構并且展示你的架構滿足了他們需求?如何集中精力在架構關鍵點上而不犧牲性能和可靠性?作為架構師你最重要的活動是什么?這些問題，都會在書中獲得答案。
全書的三個重要概念分別是視圖，視點和利益相關者。利益相關者是構建系統(tǒng)的所有人，而這些人的需求是復雜多樣，相互重疊甚至是相互沖突的。架構師的主要工作就是要知道如何與利益相關者一切工作，并且創(chuàng)造一個滿足所有人需求的架構。視點(視角)是基于利益相關者的關切，結構化的描述架構和定義架構的方法。視圖是視點的補充，主要作用是分割關切點，但主要關注跨結構的質(zhì)量屬性而不是結構本身。
利益相關者
架構的利益相關者不僅僅只是那些使用軟件的人，包括構建，測試，運維等所有對軟件系統(tǒng)有興趣的人。
A stakeholder inthe architecture of a system is an individual, team, organization, or classesthereof, having an interest in the realization of the system.
架構師如果在設計初期漏掉一個利益相關者，那么比如在未來付出代價。架構還需要在不同的利益相關者之間，沖突的需求之間做出可靠，合理的抉擇。需要注意的是，架構師本人也是一個利益相關者，必須代表自己充分的發(fā)出聲音。
The architect must ensure that there isadequate stakeholder representation across the board, including nontechnologystakeholders (such as acquirers and users) and technology-focused ones (such asdevelopers, system administrators, and maintainers).
根據(jù)角色列出利益相關者和他們關切如下：
視點
在系統(tǒng)設計過程中，有一些問題是繞不開的：架構的主要功能組件是什么?系統(tǒng)內(nèi)組件之間是如何交互的?組件與外部如何交互?系統(tǒng)的信息如何管理，存儲和表示?為了支持系統(tǒng)的這些功能，需要什么樣的硬件和軟件組件?需要提供什么的運維功能?需要提供哪些開發(fā)，測試，支持，培訓環(huán)境?這么多問題，如何理出頭緒?單一視角很難描述一個復雜系統(tǒng)架構。
和“4+1”視圖模型一樣，視點就是用結構化的多視點方式來解決上面一連串問題。
It is not possible tocapture the functional features and quality properties of a complex system in asingle comprehensible model that is understandable by and of value to allstakeholders.
在“4+1”視圖模型之后，IEEE Standard 1471更是通過標準的方式推廣這種架構方法。
A viewpoint isa collection of patterns, templates, and conventions for constructing one typeof view. It defines the stakeholders whose concerns are reflected in theviewpoint and the guidelines, principles, and template models for constructingits views.
下面是一些視點及其定義，供參考。
視圖
視點的方式本質(zhì)是做減法，分割關注點，單點突破，而視圖是用來做加法的，并且達到一加一大于二的效果。這就是架構的質(zhì)量屬性!由于用戶對質(zhì)量屬性的漠視，架構往往成為項目管理鐵三角中用來犧牲和放棄的對象。在軟件實現(xiàn)過程中，質(zhì)量屬性也往往被作為非功能需求而放棄。而這往往是架構失敗的根源。
An architectural perspective is a collection of activities,tactics, and guidelines that are used to ensure that a system exhibits aparticular set of related quality properties that require consideration acrossa number of the system’s architectural views.
因此，視圖期望提供一個質(zhì)量屬性框架，促使架構師重新審視架構中各個視點的設計和實現(xiàn)。也就是在視點中應用視圖。
一些視圖及其定義，供參考：
【本文是51CTO專欄作者石頭的原創(chuàng)文章，轉載請通過作者微信公眾號補天遺石(butianys)獲取授權】
