系統(tǒng)必然是復(fù)雜的崇猫，如何清晰準備的描述一個系統(tǒng)，是架構(gòu)工作的困難之處需忿。有兩個架構(gòu)觀點诅炉，雖然各有側(cè)重，但是殊途同歸屋厘，都是軟件架構(gòu)的基本方法涕烧。需要注意的是，這兩個架構(gòu)觀點對視圖的定義和理解略有不同汗洒，視點應(yīng)該就是視圖议纯。
“4+1”視圖模型
面對復(fù)雜和不確定的業(yè)務(wù)需求，為了避免盲人摸象的局面溢谤，使用視圖和視點的方法是比較有效的瞻凤。Philippe Kruchten在他的文章《Architectural Blueprints—The “4+1” ViewModel of Software Architecture》詳細介紹“4+1”視圖模型憨攒。在這個模型中，視圖是指從不同的利益相關(guān)者的角度來描述系統(tǒng)阀参，利益相關(guān)者可以是最終用戶肝集，開發(fā)者，也可以是項目經(jīng)理蛛壳。由此杏瞻，4個視圖就分別是邏輯視圖，開發(fā)視圖炕吸，進程視圖和物理視圖伐憾。另外“+1”的視圖是選擇一些用例和場景來描述架構(gòu)勉痴。
開發(fā)視圖：開發(fā)視圖是從程序員赫模，以及軟件管理的角度來描述系統(tǒng)。這個視圖也被稱為實現(xiàn)視圖蒸矛，往往使用UML組件圖來描述系統(tǒng)構(gòu)成瀑罗。
邏輯視圖：邏輯視圖主要描述系統(tǒng)為最終用戶提供的功能。一般對應(yīng)于UML工具的類圖雏掠，狀態(tài)圖等斩祭。
物理視圖：物理視圖是從一個系統(tǒng)工程師的角度來描述系統(tǒng)。這個視圖關(guān)切軟件組件在物理層拓撲結(jié)構(gòu)以及組件之間的物理連接乡话，通常也被稱為部署視圖摧玫。UML工具中稱為部署圖。
進程視圖：進程視圖處理系統(tǒng)的動態(tài)方面绑青，比如系統(tǒng)的進程之間如何通信以及運行時的行為诬像，比如并發(fā)，分布式闸婴，集成坏挠，性能，擴展性等邪乍。UML工具用活動圖來表示降狠。
場景視圖：場景視圖使用一些用例或者場景來描述進程和對象之間的交互，并且用來驗證架構(gòu)設(shè)計庇楞，也是架構(gòu)原型的測試起點榜配。
使用視點和視角與利益相關(guān)者合作
使用視點和視角與利益相關(guān)者合作的觀點是由NickRozanski和Eoin Woods在《軟件系統(tǒng)架構(gòu):使用視點和視角與利益相關(guān)者合作(原書第2版)》一書中闡述的。如果說有哪本書可以作為軟件架構(gòu)的教科書的話吕晌，那么非此書莫屬蛋褥。什么是架構(gòu)？為什么架構(gòu)在工作中至關(guān)重要聂使？如何確定架構(gòu)的利益相關(guān)者以及他們的關(guān)切壁拉？如何在實現(xiàn)和需求之間尋找平衡谬俄？如何和利益相關(guān)者溝通你的架構(gòu)并且展示你的架構(gòu)滿足了他們需求？如何集中精力在架構(gòu)關(guān)鍵點上而不犧牲性能和可靠性弃理？作為架構(gòu)師你最重要的活動是什么溃论？這些問題，都會在書中獲得答案痘昌。
全書的三個重要概念分別是視圖钥勋，視點和利益相關(guān)者。利益相關(guān)者是構(gòu)建系統(tǒng)的所有人辆苔，而這些人的需求是復(fù)雜多樣算灸，相互重疊甚至是相互沖突的。架構(gòu)師的主要工作就是要知道如何與利益相關(guān)者一切工作驻啤，并且創(chuàng)造一個滿足所有人需求的架構(gòu)菲驴。視點（視角）是基于利益相關(guān)者的關(guān)切，結(jié)構(gòu)化的描述架構(gòu)和定義架構(gòu)的方法骑冗。視圖是視點的補充赊瞬，主要作用是分割關(guān)切點，但主要關(guān)注跨結(jié)構(gòu)的質(zhì)量屬性而不是結(jié)構(gòu)本身贼涩。
利益相關(guān)者
架構(gòu)的利益相關(guān)者不僅僅只是那些使用軟件的人巧涧，包括構(gòu)建，測試遥倦，運維等所有對軟件系統(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.
架構(gòu)師如果在設(shè)計初期漏掉一個利益相關(guān)者，那么比如在未來付出代價袒哥。架構(gòu)還需要在不同的利益相關(guān)者之間缩筛，沖突的需求之間做出可靠，合理的抉擇统诺。需要注意的是歪脏，架構(gòu)師本人也是一個利益相關(guān)者，必須代表自己充分的發(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ù)角色列出利益相關(guān)者和他們關(guān)切如下：
Acquirers
Oversee the ?procurement of the system or product
Assessors
Oversee the ?system’s conformance to standards and legal regulation
Communicators
Explain the ?system to other stakeholders via its documentation and training materials
Developers
Construct and ?deploy the system from specifications (or lead the teams that do this)
Maintainers
Manage the ?evolution of the system once it is operational
Production ?Engineers
Design, ?deploy, and manage the hardware and software environments in which the system ?will be built, tested, and run
Suppliers
Build and/or ?supply the hardware, software, or infrastructure on which the system will run
Support Staff
Provide ?support to users for the product or system when it is running
System ?Administrators
Run the system ?once it has been deployed
Testers
Test the ?system to ensure that it is suitable for use
Users
Define the ?system’s functionality and ultimately make use of it
視點
在系統(tǒng)設(shè)計過程中婿失，有一些問題是繞不開的：
架構(gòu)的主要功能組件是什么？
系統(tǒng)內(nèi)組件之間是如何交互的啄寡？組件與外部如何交互豪硅？
系統(tǒng)的信息如何管理，存儲和表示挺物？
為了支持系統(tǒng)的這些功能懒浮，需要什么樣的硬件和軟件組件？
需要提供什么的運維功能？
需要提供哪些開發(fā)砚著，測試次伶，支持，培訓(xùn)環(huán)境稽穆？
這么多問題冠王，如何理出頭緒？單一視角很難描述一個復(fù)雜系統(tǒng)架構(gòu)舌镶。
和“4+1”視圖模型一樣柱彻，視點就是用結(jié)構(gòu)化的多視點方式來解決上面一連串問題。
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更是通過標準的方式推廣這種架構(gòu)方法哟楷。
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.
下面是一些視點及其定義，供參考否灾。
Context
Describes ?the relationships, dependencies, and interactions between the system and its ?environment (the people, systems, and external entities with which it ?interacts). Many architecture descriptions focus on views that model the system’s ?internal structures, data elements, interactions, and operation. Architects ?tend to assume that the “outward-facing” information — the system’s runtime ?context, its scope and requirements, and so forth – is clearly and ?unambiguously defined elsewhere. However, you often need to include a ?definition of the system’s context as part of your architectural description.
Functional
Describes ?the system’s functional elements, their responsibilities, interfaces, and ?primary interactions. A Functional view is the cornerstone of most ADs and is ?often the first part of the description that stakeholders try to read. It ?drives the shape of other system structures such as the information ?structure, concurrency structure, deployment structure, and so on. It also ?has a significant impact on the system’s quality properties such as its ?ability to change, its ability to be secured, and its runtime performance.
Information
Describes ?the way that the architecture stores, manipulates, manages, and distributes ?information. The ultimate purpose of virtually any computer system is to ?manipulate information in some form, and this viewpoint develops a complete ?but high-level view of static data structure and information flow. The ?objective of this analysis is to answer the big questions around content, ?structure, ownership, latency, references, and data migration.
Concurrency
Describes ?the concurrency structure of the system and maps functional elements to concurrency ?units to clearly identify the parts of the system that can execute ?concurrently and how this is coordinated and controlled. This entails the ?creation of models that show the process and thread structures that the ?system will use and the interprocess communication mechanisms used to ?coordinate their operation.
Development
Describes ?the architecture that supports the software development process. Development ?views communicate the aspects of the architecture of interest to those ?stakeholders involved in building, testing, maintaining, and enhancing the ?system.
Deployment
Describes ?the environment into which the system will be deployed, including capturing ?the dependencies the system has on its runtime environment. This view ?captures the hardware environment that your system needs (primarily the ?processing nodes, network interconnections, and disk storage facilities ?required), the technical environment requirements for each element, and the ?mapping of the software elements to the runtime environment that will execute ?them.
Operational
Describes ?how the system will be operated, administered, and supported when it is ?running in its production environment. For all but the simplest systems, ?installing, managing, and operating the system is a significant task that ?must be considered and planned at design time. The aim of the Operational ?viewpoint is to identify system-wide strategies for addressing the ?operational concerns of the system’s stakeholders and to identify solutions ?that address these.
視圖
視點的方式本質(zhì)是做減法卖擅，分割關(guān)注點，單點突破坟冲，而視圖是用來做加法的磨镶，并且達到一加一大于二的效果溃蔫。這就是架構(gòu)的質(zhì)量屬性健提！由于用戶對質(zhì)量屬性的漠視，架構(gòu)往往成為項目管理鐵三角中用來犧牲和放棄的對象伟叛。在軟件實現(xiàn)過程中私痹，質(zhì)量屬性也往往被作為非功能需求而放棄。而這往往是架構(gòu)失敗的根源统刮。
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ì)量屬性框架，促使架構(gòu)師重新審視架構(gòu)中各個視點的設(shè)計和實現(xiàn)侥蒙。也就是在視點中應(yīng)用視圖暗膜。
一些視圖及其定義，供參考：
Accessibility
The ?ability of the system to be used by people with disabilities
Availability and Resilience
The ?ability of the system to be fully or partly operational as and when required ?and to effectively handle failures that could affect system availability
Development Resource
The ?ability of the system to be designed, built, deployed, and operated within ?known constraints around people, budget, time, and materials
Evolution
The ?ability of the system to be flexible in the face of the inevitable change ?that all systems experience after deployment, balanced against the costs of ?providing such flexibility
Internationalization
The ?ability of the system to be independent from any particular language, ?country, or cultural group
Location
The ?ability of the system to overcome problems brought about by the absolute ?location of its elements and the distances between them
Performance and Scalability
The ?ability of the system to predictably execute within its mandated performance ?profile and to handle increased processing volumes
Regulation
The ?ability of the system to conform to local and international laws, quasi-legal ?regulations, company policies, and other rules and standards
Security
The ?ability of the system to reliably control, monitor, and audit who can perform ?what actions on what resources and to detect and recover from failures in ?security mechanisms
Usability
The ?ease with which people who interact with the system can work effectively
