最近要考試了，綜合了一下老師的PPT和其他同學整理的資料。如果存在什么問題，可以留評論

1.各種性能指標的定義及如何到達各種性能指標的方法

• 吞吐量 （Throughput）
  定義：單位時間內成功地傳送數據的數量
  實現：Average 平均，Peak 峰值
  許多系統具有低平均但高峰值吞吐量的需求

• 響應時間（Response Time）
  定義：應用程序在處理請求時顯示延遲的時間
  實現：Guaranteed time 最大響應時間 Average time 平均響應時間
  95%的響應在4秒以內，全部在10秒之內

• 最后期限（Deadlines）
  定義：有些事情必須在指定的時間之前完成
  實現：最后期限通常與IT系統中的批處理作業相關。

2.常用的中間件有那幾種類型（四種）

中間件是一種獨立的系統軟件或服務程序，分布式應用軟件借助這種軟件在不同的技術之間共享資源。

• Business Process Orchestrators 業務流程
  例子：BizTalk, TIBCO StaffWare, ActiveBPEL
• Message Brokers 消息代理
  例子：BizTalk, WebSphere Message Broker, SonicMQ
• Application Servers 應用服務器
  例子：J2EE, CCM, .NET
• Transport 傳輸
  例子：Message-Oriented Middleware, Distributed Objects Systems

面向消息的中間件，分布式對象系統

1）CORBA---公用對象請求代理（調度）程序體系結構，它在對象間建立客戶-服務器的關系，這樣一個客戶可以很簡單地使用服務器對象的方法而不論服務器是在同一機器上還是通過一個網絡訪問。 （常見的對象請求代理架構）
2）Basic Message-oriented middleware---- MOM指的是利用高效可靠的消息傳遞機制進行平臺無關的數據交流，并基于數據通信來進行分布式系統的集成。通過提供消息傳遞和消息排隊模型，它可在分布環境下擴展進程間的通信，并支持多通訊協議、語言、應用程序、硬件和軟件平臺。 （面向消息的中間件）
3）J2EE---- J2EE核心是一組技術規范與指南，其中所包含的各類組件、服務架構及技術層次，均有共同的標準及規格，讓各種依循J2EE架構的不同平臺之間，存在良好的兼容性，解決過去企業后端使用的信息產品彼此之間無法兼容，企業內部或外部難以互通的問題。
4）Message brokers----消息代理是一種在數據源與目的地之間移動數據使信息處理流暢的軟件技術，數據源與目的地包括已有的應用、文件、數據庫、對象、硬拷貝輸出及Web客戶端等。 （消息代理）
5）Business process orchestrators----“業務過程的部分或整體在計算機應用環境下的自動化”，它主要解決的是“使在多個參與者之間按照某種預定義的規則傳遞文檔、信息或任務的過程自動進行，從而實現某個預期的業務目標，或者促使此目標的實現”。（業務過程代理）

3.有那些常見架構風格

1）管道和過濾器（Pipe and Filter）

• 管道-過濾器模式的體系結構是面向數據流的軟件體系結構。
• 它最典型的應用是在編譯系統。
• 一個普通的編譯系統包括詞法分析器,語法分析器,語義分析與中間代碼生成器,優化器,目標代碼生成器等一系列對源程序進行處理的過程。
• 人們可以將編譯系統看作一系列過濾器的連接體,按照管道-過濾器的體系結構進行設計。
• 此外,這種體系結構在其它一些領域也有廣泛的應用。因此它成為軟件工程和軟件開發中的一個突出的研究領域。
• 舉例：unix的shell腳本、傳統編譯器

2）面向對象（Object-Oriented）

• 適用于主要問題是識別和保護信息的相關主體。 數據代理和它們相關的操作封裝在一個抽象數據類型里面。
• 舉例：java，c#開發的系統

3）隱式調用（Implicit Invocation）

• 隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件。
• 基于事件的系統中的其它構件中的過程在一個或多個事件中注冊，當一個事件被觸發，系統自動調用在這個事件中注冊的所有過程，這樣，一個事件的觸發就導致了另一模塊中的過程的調用。
• 支持基于事件的隱式調用的應用系統很多。例如，在編程環境中用于集成各種工具，在數據庫管理系統中確保數據的一致性約束，在用戶界面系統中管理數據，以及在編輯器中支持語法檢查。例如在某系統中，編輯器和變量監視器可以登記相應Debugger的斷點事件。當Debugger在斷點處停下時，它聲明該事件，由系統自動調用處理程序，如編輯程序可以卷屏到斷點，變量監視器刷新變量數值。而Debugger本身只聲明事件，并不關心哪些過程會啟動，也不關心這些過程做什么處理。
• 舉例：數據庫管理系統中執行完整性約束（觸發器）。
  在用戶界面中用于將數據表示與管理該數據的應用程序分離。

4）客戶-服務器風格

• 客戶服務器方式（簡稱C/S方式），為網絡邊緣的系統中運行的程序之間的一種通信方式。描述的是進程之間服務和被服務的關系，客戶是服務請求方，服務器是服務提供方。客戶服務器模式是一種分布式系統體系結構。
• 客戶（client）和服務器（server）都是指通信中所涉及的兩個應用程序?？蛻舴掌鞣绞矫枋龅氖沁M程之間服務和被服務的關系。這里所說的客戶和服務器都指的是計算機進程（軟件）。在C/S方式中，請求一方為客戶，響應請求一方稱為服務器，如果一個服務器在響應客戶請求時不能單獨完成任務，還可能向其他服務器發出請求，這時，發出請求的服務器就成為另一個服務器的客戶。從雙方建立聯系的方式來看，主動啟動通信的應用叫客戶，被動等待通信的應用叫服務器。這里最主要的特征就是：客戶是服務請求方，服務器是服務提方。
• 舉例：文件服務器、數據庫服務器、對象服務器

5）分層風格

• 把應用的關注點分割為堆棧組（層）。
• 適用于涉及到分布式的能夠分層的組織的類的服務，每層給它的上一層提供服務，同時作為下一層的客戶端，只有仔細地從內層選擇選擇過程，才能用于他們臨近的外層。
• 分層架構的一個重要原則是：每層只能與位于其下方的層發生耦合。分層架構也分為幾種：在嚴格分層架構中，某層只能與直接位于其下方的層發生耦合；而松散分層架構則允許任意上方層與任意下方層發生耦合。由于用戶界面層和應用服務通常需要與基礎設施打交道，許多系統都是基于松散分層架構的。
• 舉例：分層通信協議、操作系統

6）倉庫風格

• 適用于主要問題是建立、增加和維護復雜信息的主體部分，信息一定要能夠用很多種方式操作。經常需要長期的存在。
• 優點：有效存儲大量數據、共享式模式模型、集中式管理
• 缺點：必須先達成一個數據模型、很難分配數據、數據升級很昂貴
• 舉例：信息系統、編程環境、圖形編輯器、人工智能知識基礎、逆向工程系統

7）解釋程序風格

• 解釋程序是一種語言處理程序，在詞法、語法和語義分析方面與編譯程序的工作原理基本相同，但在運行用戶程序時，它直接執行源程序或源程序的內部形式(中間代碼)。因此，解釋程序并不產生目標程序，這是它和編譯程序的主要區別。
• 適用于執行 解決方案的最合適的語言 或是 機器不是直接可用的。
• 舉例：編程語言編譯器、基于規則的系統、腳本語言

8）過程控制風格

• 適用于目的是維護特殊過程的輸出屬性在給定參考值的情形下
• 舉例：實時系統軟件用來控制（核電站、汽車巡航控制）

補充內容：
分布式系統（distributed system）是建立在網絡之上的軟件系統。分布式系統是由一組通過網絡進行通信、為了完成共同的任務而協調工作的計算機節點組成的系統。分布式系統的出現是為了用廉價的、普通的機器完成單個計算機無法完成的計算、存儲任務。其目的是利用更多的機器，處理更多的數據。

4.架構師需要的核心技能是什么
1） 團隊之間的交流 Liaison with stakeholders
2） 技術知識 Technology knowledge
3） 軟件工程學 Software engineering
4） 風險管理 Risk managements

(來源 ppt 18頁)

5.什么是軟件架構（好幾種定義，但是主要點是結構，元素，關系，接口）
（百度百科）

• 軟件架構（software architecture）是一系列相關的抽象模式，用于指導大型軟件系統各個方面的設計。
• 軟件架構是一個系統的草圖。

（PPT ch1-ch8 slide 3- 7）

• It’s about software design
  軟件架構是軟件設計過程的一部分。
  All architecture is software design, but not all design is software architecture
  所有的架構都是軟件設計，但不是所有的設計都是軟件架構
  Part of the design process
  設計過程的一部分

• Simply, architecture focuses on ‘issues that will be difficult/impossible to change once the system is built’
  簡單地說，架構關注的是“一旦構建系統，就很難/不可能更改的問題”
  Quality attributes like security, performance
  質量屬性，如安全性、性能
  Non-functional requirements like cost, deployment hardware
  非功能性需求，如成本、部署硬件

-“Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
體系結構是一個系統的基本組織，體現在它的組件、它們彼此之間的關系和環境中，以及控制它的設計和演進的原則中。

“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”
程序或計算系統的軟件架構是 系統的一個或多個結構，
它包括 軟件元素、這些元素的外部可見屬性 和 它們之間的關系。

6.軟件架構主要關注那些問題
（來源PPT）
‘issues that will be difficult/impossible to change once the system is built’
“一旦系統建立后就很難或是不可能改變的問題”:
Quality attributes like security, performance
質量屬性,例如 安全性 , 性能
Non-functional requirements like cost, deployment hardware
非功能性需求,像開銷, 硬件配置

7.現代復雜軟件設計的主要問題是那些

可能的答案 L1-8 Slide3
Major problems are architecture design, technology selection, application and business integration
主要問題是 架構設計 、技術選擇、 應用 和 業務集成

8.什么是架構風格
（百度百科來源）

• 軟件體系結構風格是描述某一特定 應用領域 中 系統組織方式 的 慣用模式。
• 體系結構風格定義一個系統家族，即一個體系結構定義一個詞匯表和一組約束。詞匯表中包含一些構件和連接件類型，而這組約束指出系統是如何將這些構件和連接件組合起來的。

9.什么是架構視圖
（來源doc）
架構視圖：

• 對于從 某一視角 或 某一點 上看到的系統所做的 簡化描述 ，
• 描述中涵蓋了系統的 某一特定方面 ，而省略了此方面無關的 實體 。

10.非功能需求包括哪些（三種）

NFRs（Non-functional requirements）:非功能性需求:

• Technical constraints 技術約束
• Business constraints 業務約束
• Quality attributes 質量屬性
  是對整個系統性能等方面的 評估和驗證
  (來源PPT 12)

11.軟件架構過程（三個迭代步驟）

1.png

1）確定架構需求：架構上重要的需求（結構用例）---基本的質量和系統的非功能性需求
2）架構設計：迭代的設計步驟---風險識別是一個重要的輸出設計
3）結構驗證：

• 驗證階段---驗證階段的目的是增加信心的設計團隊的架構是適合的目的；
• 驗證必須實現在項目時間和預算的約束，關鍵是要盡可能嚴格的和有效的；
• 驗證一個架構設計提出了嚴峻的挑戰，因為這是一個設計不能執行或測試，包括新和COTS組件集成；
  (來源 doc ppt202)

12.軟件質量屬性主要包括哪些（五種）

• Reliability 可靠性：
  可靠性參數：平均故障間隔時間（MTBF），顧名思義，是硬件模塊故障之間的平均時間。它是制造商在硬件模塊發生故障之前估計的平均時間。
  FITS是表示MTBF的更直觀的方式。FITS只是十億小時（即1000,000,000小時）內模塊的故障總數。
• Availability 可用性：
  衡量系統的可用性可以用公式 MTBF／(MTBF+MTTR)，其中MTBF為系統出錯的時間間隔也就是平均正常工作時間，而MTTR表示系統修復錯誤用的時間。當然上面的公式計算出的結果越大表示系統的可用性越好。
• Portability 可移植性：跨平臺
• Scalability 可伸縮性：擴展的彈性
• Performance (!) 性能：快

ppt1-8 116頁

13.軟件可用性取決于（三種時間）

• Time to detect failure 故障 檢測 時間
• Time to correct failure 糾正 失敗時間
• Time to restart application 重新啟動 應用程序時間
  (PPT 146頁)

14.伸縮性涉及那些方面（四種）

• 伸縮性定義：(來源 百度百科) 可伸縮性/可擴展性(Scalable/scalability)

• 可伸縮性(可擴展性)是一種對軟件系統計算處理能力的設計指標，高可伸縮性代表一種彈性，在系統擴展成長過程中，軟件能夠保證旺盛的生命力，通過很少的改動甚至只是硬件設備的添置，就能實現整個系統處理能力的線性增長，實現高吞吐量和低延遲高性能。

• 可伸縮性和純粹性能調優有本質區別， 可伸縮性是高性能、低成本和可維護性等諸多因素的綜合考量和平衡，可伸縮性講究平滑線性的性能提升，更側重于系統的水平伸縮，通過廉價的服務器實現分布式計算；而普通性能優化只是單臺機器的性能指標優化。他們共同點都是根據應用系統特點在吞吐量和延遲之間進行一個側重選擇，當然水平伸縮分區后會帶來CAP定理約束。

• 縱向的可伸縮性——在同一個邏輯單元內增加資源來提高處理能力。這樣的例子包括在現有服務器上增加CPU，或者在現有的RAID/SAN存儲中增加硬盤來提高存儲量。

• 橫向的可伸縮性——增加更多邏輯單元的資源，并令它們像是一個單元一樣工作。大多數集群方案、分布式文件系統、負載平衡都是在幫助你提高橫向的可伸縮性

1）Request load 請求負載
當同步請求負載增長時，100個tps應用程序的行為如何?如。
每秒100到1000個請求?
理想的解決方案，無需額外的硬件容量:
隨著負載的增加，吞吐量保持不變(即100 tps)，每個請求的響應時間只線性增加(即10秒)。

2）Connections 連接
如果與應用程序同時連接的數量增加，會發生什么情況呢
如果每個連接都消耗資源?
超過連接的最大數量?
ISP的例子:
每個用戶連接生成一個新進程
每個服務器上的虛擬內存超過2000個用戶
需要支持100k用戶

3）Data size 數據大小
當應用程序處理的數據增大時，它的行為如何?
聊天應用程序平均消息大小翻倍?
數據庫表大小從100萬行增長到2000萬行?
圖像分析算法處理100MB而不是1MB的圖像?
應用程序/算法能否擴展以處理增加的數據需求?

4）Deployments 部署
安裝/部署應用程序的工作量如何隨著安裝基數的增長而增加?
安裝新用戶?
安裝新的服務器?
解決方案通常圍繞自動下載/安裝
例如從互聯網下載應用程式
ppt1-8 127頁

15.吞吐率指標
PPT 120
Measure of the amount of work an application must perform in unit time
度量應用程序在單位時間內必須執行的工作量

• Transactions per second 每秒事務數
• Messages per minute 每分鐘的消息

PPT 121
Throughput of a message queuing system ：
消息隊列系統的吞吐量

• Messages per second (msp) 每秒的信息
• Maximum sustainable throughput (MST) 最大可持續吞吐量

16.架構元素的通信包括哪些

（PPT ch1-ch8 slide210、212、218）

• Synchronous communications 同步通信
• Asynchronous communications 異步通信
• Flexible communications 靈活通信

（PPT ch1-ch8 10）
Architecture Specifies Component Communication 體系結構指定組件通信
Communication involves: 架構元素的通信：

Data passing mechanisms 數據傳遞機制：

• Function call 函數調用
• Remote method invocation 遠程方法調用
• Asynchronous message 異步消息

Control flow 控制流

• Flow of messages between components to achieve required functionality
  組件之間的消息流來實現需要的功能
• Sequential 順序
• Concurrent/parallel 并發/并行
• Synchronization 同步

17.各種架構風格的組件和連接器是什么

1）管道和過濾器架構風格PPT 40頁
組件：稱為過濾器，應用于對局部的輸入流的轉換，經常增長的計算，因此，在輸入結束前輸出就開始了。
連接器：稱為管道，給流提供管道，把一個過濾器的輸出傳輸到另一個輸入。

2）面向對象風格 PPT49頁
組件：對象
連接器：功能和過程調用（方法）

3）隱式調用風格
組件：模塊（？？？）
連接器：廣播系統
隱式調用系統中的連接器除了
事件通知 過程調用 之間的綁定外，
通常還包括 傳統的過程調用

4）客戶-服務器風格 PPT64頁
組件：服務器：標準獨立的組件提供特別的服務，如打印，數據管理等?？蛻舳耍航M件調用服務器提供的服務。
連接器：網絡，允許客戶端訪問遠程服務器。

5）分層風格 PPT72頁
組件：典型的過程的集合。
連接器：典型的在有限的可見性下的過程調用

6）倉庫風格 PPT80頁
組件：
表示系統正確狀態的中心數據結構。
A central data structure representing the correct state of the system.
操作中心數據結構的獨立組件的集合。
A collection of independent components that operate on the central data structure.
連接器：典型地過程調用或是直接內存訪問

7）解釋程序風格 PPT87頁
組件：
包括執行引擎的一個狀態機和三個內存:
include one state machine for the execution engine and three memories:
執行引擎的當前狀態
current state of the execution engine
程序解釋
program being interpreted
正在解釋的程序的當前狀態
current state of the program being interpreted
連接器：
procedure calls 過程調用
direct memory accesses. 直接內存訪問

8）過程控制風格 PPT94頁
組件：過程定義：包括操作一些過程變量的機制，控制算法：決定如何去操作過程變量
連接器： 數據流關系 data flow relations

18.軟件性能指標主要有哪幾種（三種）

吞吐量、響應時間、最后期限 見第一題

19.響應時間的度量（兩種）

Guaranteed time 最大響應時間
Average time 平均響應時間

PPT 122

20.安全性質量指標主要有哪幾種（五種）

• Authentication: Applications can verify the identity of their users and other applications with which they communicate.
  身份驗證：應用程序可以驗證他們的用戶的身份和他們通信的其他應用程序。
• Authorization: Authenticated users and applications have defined access rights to the resources of the system.
  授權：身份驗證的用戶和應用程序定義了系統資源的訪問權限。
• Encryption: The messages sent to/from the application are encrypted.
  加密：從應用程序發送到/從應用程序的消息是加密的。
• Integrity: This ensures the contents of a message are not altered in transit.
  完整性：確保在傳輸過程中不會改變消息的內容。
• Non-repudiation: The sender of a message has proof of delivery and the receiver is assured of the sender’s identity. This means neither can subsequently refute their participation in the message exchange.
  不可否認性：消息的發送方有交付證明，接收方可以確定發送方的身份。這意味著，雙方隨后都不能否認他們參與了信息交換。

PPT 142頁

21.實現高可用性的策略（三種）

• Eliminate single points of failure 消除單點故障
  是指一個系統的這樣一個部件，如果它失效或停止運轉，將會導致整個系統不能工作。我們當然不希望看到，在一個要求高度可用性的系統中存在這樣的部分，但這種情況在網絡，軟件應用以及其它工業系統中都存在。
• Replication and failover 復制和故障轉移
  failover n. 失效備援（為系統備援能力的一種，當系統中其中一項設備失效而無法運作時，另一項設備即可自動接手原失效系統所執行的工作）
• Automatic detection and restart 自動檢測和重新啟動

PPT 146

22.信息隱藏原理

PPT lecture 9 88頁

• 信息隱藏指在設計和確定模塊時，使得一個模塊內包含的特定信息（過程或數據），對于不需要這些信息的其他模塊來說，是不可訪問的。
• 信息隱藏（封裝）主要是為了提高軟件的可重用性和可維護性。信息隱藏造成了系統各個部分耦合性低。系統是由各個部分構成的，如果這些部分耦合性低的話，那么這個系統開發、維護等就較容易。
• 假設A打算秘密傳遞一些信息給B，A需要從一個隨機消息源中隨機選取一個無關緊要的消息C，當這個消息公開傳遞時，不會引起人們的懷疑，稱這個消息為載體對象（Cover Message）C；把秘密信息（Secret Message）M隱藏到載體對象C中，此時，載體對象就變成了偽裝對象C1.載體對象C是正常的，不會引起人們的懷疑，偽裝對象C1與載體對象C無論從感官（比如感受圖像、視頻的視覺和感受聲音、音頻的聽覺）上，還是從計算機的分析上，都不可能把他們區分開來，而且對偽裝對象C1的正常處理，不應破壞隱藏的秘密信息。這樣就實現了信息的隱藏傳輸。秘密信息的嵌入過程可能需要密鑰，也可能不需要密鑰，為了區別于加密的密鑰，信息隱藏的密鑰稱為偽裝密鑰k。

信息隱藏涉及兩個算法：信息嵌入算法和信息提取算法，如下圖：
信息隱藏的原理框圖

1.png

23.關注點分離
關注點分離（Separation of concerns，SOC）：
Presentation, business and data handling logic are clearly partitioned in different tiers.
表示、業務和數據處理邏輯清楚地劃分在不同的層中。
ppt 210

SoC是將軟件分解成不同的特性的過程，這些特性封裝了其他類可以使用的獨特行為和數據。通常，關注點表示類的特性或行為。將程序分離成離散職責的行為顯著地提高了代碼重用、維護和可測試性。
PPT Review of Java Slide 36

關注點分離（Separation of concerns，SOC）
1）大體思路是,先將復雜問題做合理的分解,再分別仔細研究問題的不同側面(關注點)，最后綜合各方面的結果，合成整體的解決方案。
2）是對只與“特定概念、目標”(關注點)相關聯的軟件組成部分進行“標識、封裝和操縱”的能力，即標識、封裝和操縱關注點的能力。是處理復雜性的一個原則。由于關注點混雜在一起會導致復雜性大大增加，所以能夠把不同的關注點分離開來，分別處理就是處理復雜性的一個原則，一種方法。

關注點分離是面向方面的[程序設計]的核心概念。分離關注點使得解決特定領域問題的代碼從業務邏輯中獨立出來，業務邏輯的代碼中不再含有針對特定領域問題代碼的調用(將針對特定領域問題代碼抽象化成較少的程式碼，例如將代碼封裝成function或是class)，業務邏輯同特定領域問題的關系通過側面來封裝、維護，這樣原本分散在在整個應用程序中的變動就可以很好的管理起來。
百度百科

24.什么是職責驅動的設計

Responsibility-Driven Design (RDD)

• Detailed object design is usually done from the point of view of the metaphor of:
  詳細的對象設計通常是從隱喻的角度進行的:
  1.Objects have responsibilities
  對象有責任
  2.Objects collaborate
  合作對象

• Responsibilities are an abstraction.
  責任是抽象的。
  1.The responsibility for persistence.
  堅持的責任。
  Large-grained responsibility.
  大粒度的責任。
  2.The responsibility for the sales tax calculation.
  負責營業稅的計算。
  More fine-grained responsibility.
  更細粒度的責任。
  ppt

• 職責驅動設計即如何給相互協作的對象分配職責，主要關注的是職責、角色以及協作。

• 職業驅動設計就是職責必須匹配。
  什么是職責呢？簡單地說，一個類或構件的職責包括兩個方面：
  一個是知道的事，對于一個類來說就是他的屬性；
  一個是能做的事，對于一個類來說就是他的方法。
  百度百科

25.GRASP模式的具體內容，各種模式的定義，解決的什么問題

1）創造者 Creator
分配給類B職責來創造類A的一個實例如果：
（1） B聚合A的對象
（2） B包含A的對象
（3） B記錄A的對象的實例
（4） B緊密地使用A的對象
（5） B被創建時有初始化的數據傳遞給

解決方案：將創建一個類A的實例的職責指派給類B的實例，
如果下列條件滿足的話：
a) B聚合了A對象
b) B包含了A對象
c) B紀錄了A對象的實例
d) B要經常使用A對象
e) 當A的實例被創建時，B具有要傳遞給A的初始化數據(也就是說B是創建A的實例這項任務的信息專家)
f) B是A對象的創建者
如果以上條件中不止一條成立的話，那么最好讓B聚集或包含A

通俗點就是：我要用你所以我來創建你，請不要讓別人創建你
這個模式是支持低耦合度原則的一個體現

2）信息專家 Information Expert
在設計對象（類）時，如果某個類能夠在某方面具有完整信息，足以實現某責任，就將這個責任分配給這個類，
解決方案：將職責分配給具有履行職責所需要的信息的類
通俗點就是：該干嘛干嘛去，別管別人的閑事或者我的職責就是搞這個，別的事不管。
舉個簡單的例子，如果有一個類是專門處理字符串相關的類，那么這個類只能有字符串處理相關的方法，而不要將日期處理的方法加進來。也就是提高軟件高內聚一種原則。

3）控制器 Controller
控制器是在用戶接口層上的第一個對象，負責接收和處理系統的操作信息。
解決方案：將處理系統事件消息的職責分派給代表下列事物的類：
a) 代表整個“系統”的類（虛包控制者）
b) 代表整個企業或組織的類（虛包控制者）
c) 代表真實世界中參與職責（角色控制者）的主動對象類（例，一個人的角色）
d) 代表一個用況中所有事件的人工處理者類，通常用“<用例名>處理者”的方式命名（用例控制者）
這是一個控制者角色職責分配的原則，就是哪些控制應該分派給哪個角色。

4）低耦合 Low Coupling
測量存在于模塊之間的依賴程度
解決方案：在分配一個職責時要使保持低耦合度。
耦合度(coupling)是一個類與其它類關聯、知道其他類的信息或者依賴其他類的強弱程度的度量。一個具有低(弱)耦合度的類不依賴于太多的其他類。

5）高內聚 High Cohesion
測量一個共享的模塊內元素的相關性 ；一個單獨模塊執行任務的程度是功能相關的
解決方案：分配一個職責的時候要保持類的高聚合度
聚合度或內聚度(cohesion)是一個類中的各個職責之間相關程度和集中程度的度量。一個具有高度相關職責的類并且這個類所能完成的工作量不是特別巨大，那么他就是具有高聚合度。

6）多態 Polymorphism
當相關的供選方案或行為隨著類型的變化而變化時，給行為分配職責—使用多態操作—來適合行為變化的類型。
也就是說盡量對抽象層編程，用多態的方法來判斷具體應該使用那個類，而不是用if instanceof 來判斷該類是什么接來執行什么。

7）純虛構 Pure Fabrication
分配一系列高度聚合的職責給虛假的類或是不表現某事完成的領域問題概念的有用的類，它支持高內聚、低耦合、可重用。
一個純虛構意味著虛構某些事物，而不是到了迫不得已我們才這樣做。
例，我們的Sale類的數據要存入數據庫，但是他必須和數據庫接口相連接，如果將接口連接放入Sale類中勢必增加該類的耦合度，所以我們可以虛構一個類來處理與數據庫接口連接的問題。這個類就是我們虛構出來的一個事物。

8）間接 Indirection
問題：如何分配職責避免直接耦合？如何減弱對象的耦合？
解決方案：分配職責給中間的調解對象來調解兩個組件之間的關系。
內容：將職責分配給一個中間對象以便在其他構件或服務之間仲裁，這樣這些構件或服務沒有被直接耦合。這個中間對象(intermediary)在其他構件或服務間創建一個中介者(Indirection)。這個中間對象也就事7)中的純虛構。

9）防止編譯/變化預防 Protected Variations
問題：如何設計對象，子系統和系統，使其內部的變化和不穩定不會對其他元素產生不良影響？
解決方案：識別設計變化或不穩定之處，分配職責用以在這些變化之外創建穩定接口
內容：分配職責給一個客戶端的直接對象以使它與一個間接對象進行協作，這樣客戶端無需知道這個間接對象。
這個模式-也被叫做(Demeter)準則。
通俗點就是：只與你直接的朋友們通信，不要跟“陌生人”說話，每個軟件單位對其他的單位都只有最少的知識，而且局限于那些與本單位密切相關的軟件單位

GRASP的主要特征：

• 對象職責分配的基本原則。
• 主要應用在分析和建模上。

GRASP的核心思想的理解：

• 自己干自己的事（職責的分配）
• 自己干自己的能干的事（職責的分配）
• 自己只干自己的事（職責的內聚）

來源 doc

26.OO設計的五個基本原則及課件中講述的其它軟件原理

五個基本原則：（S.O.L.I.D）:
1）單一職責原則 (SPR 單一功能原則)
這個原則和關注點分離緊密聯系。它陳述了每個對象應該只有一個理由去改變，單一聚焦在職責上。通過依附這個原則，你避免了龐大的類的設計問題，那就像瑞士的軍刀。有了精確的對象，你再次增加了系統的可讀性和可維護性。

2）開閉原則 (OCP 開閉原則)
這個原則陳述了類應該對擴展開放，對修改關閉，那樣你就能夠添加新的特征，擴展一個類而不用改變它內部的行為。這個原則旨在避免破壞存在的類及依賴它的其他類，這使得你的整個應用程序中產生故障和錯誤的漣漪。

3)Liskov替換原則 (LSP 里式替換原則)
Liskov替換原則要求你應該能夠使用任何衍生出的類代替父類，不用修改就有同樣的行為。這個原則與開閉原則一致，它保證了一個衍生出的類不影響父類的行為，或者說，衍生出的類必須能夠被它們的基類替代。

4)接口分離原則 (ISP 接口隔離原則)
這個原則是將一個抽象方法分裂成幾組職責，給這些組分配接口來防止客戶端實現一個很大的接口，這個接口容納了很多它們不使用的方法。目的是為了讓類使用相同的接口只需要實現一些具體的方法，而不是有很多方法的龐大的接口。不應強迫客戶程序實現一個它用不上的接口。

5)依賴反轉原則 (DIP依賴反轉原則)
把你的類從具體的實現中隔離開，使它們依賴于抽象類或接口。它促進了對接口而不是實現的譯碼，這通過保證對實現的低耦合來增加系統的靈活性。
高層模塊不應該依賴于底層模塊。二者都應該依賴于抽象。
抽象不應該依賴于細節，細節應該依賴于抽象。

更多解釋：
https://blog.csdn.net/zn_echonn/article/details/80198053

【其它基本原理】
A.保持代碼簡單而不過于簡單，避免不必要的復雜性；
B.把公共事物抽象出來，放在固定的位置；
C.給類分配正確的職責，告訴對象做什么，而不是詢問對象的狀態；
D.把自認為需要卻不一定需要的特性延遲；
E.把特性分離封裝成類，增強重用、維護和穩定。（關注點分離）
F.將類及其成員的訪問性降到最小；
G.使用訪問器和修改器，而不是公共成員；
H.組合優于繼承；
I.面向接口編程，而不是實現。

• 面向抽象原則
  設計一個類時，不讓該類面向具體的類，而是面向抽象類或接口
• 高內聚-低耦合原則
  如果類中的方法是一組相關的行為，則稱該類是高內聚的，反之稱為低內聚的。 所謂低耦合就是盡量不要讓一個類含有太多的其它類的實例的引用，以避免修改系統的其中一部分會影響到其它部分。

27.組合，繼承，針對接口編程，黑盒，白盒重用

1）組合：
指在新類里面創建原有類的對象，重復利用已有類的功能。

優點：
包含對象由包含類通過其接口訪問
“黑盒”重用，因為包含對象的內部細節不可見

• 良好的封裝
• 更少的實現依賴性
• 每個類只關注一個任務
• 可以在運行時通過獲取對相同類型的其他對象的引用的對象來動態地定義組合
  缺點：
  結果系統往往有更多的對象
  接口必須仔細定義，以便使用許多不同的對象作為組合塊

2）繼承：

新功能的重用方法獲得通過擴展現有對象的實現 ？？？
繼承是從已有的類中派生出新的類，新的類能吸收已有類的數據屬性和行為，并能擴展新的能力。
泛化類(超類)明確了共同的屬性和方法
專業類(子類)擴展了實現額外的屬性和方法

優點：
新的實現很容易，因為它的大部分是繼承的
容易修改或擴展的實現被重用
缺點：
打破封裝，因為它暴露一個子類到其超類的實現細節
“白盒”重用，因為超類的內部細節對子類通常是可見的
如果超類的實現更改，則可能必須更改子類
從超類繼承的實現不能在運行時更改

3）針對接口編程又稱為面向接口編程，

針對接口編程就是要先設計以系列的接口，把設計和實現分開，使用時只需要引用接口即可，也由于系統各部分的解耦合。針對接口編程是為了提高程序的可維護性、可伸縮性和可復用性。如果你在一個類中直接使用另外的一個，這樣就把兩個類緊密聯系在一起了，以后如果想做出改變就很難了。如果針對接口編程，當業務變化時我們只需要用一個新的類實現接口即可

優點：
客戶端不知道他們正在使用的對象的特定類
一個對象可以很容易地被另一個替換
對象連接不需要硬連線到特定類的對象，從而增加了靈活性
松耦合
增加重復使用的可能性
改進合成的機會，因為包含的對象可以是實現特定接口的任何類
缺點：
適度增加設計復雜性

4）白盒復用：
源代碼可見，可修改和擴展
– 復制已有代碼當正在開發的系統，進行修改
– 可定制化程度高
– 對其修改增加了軟件的復雜度，且需要對其內部充分的了解

白盒重用"White-box" reuse（PPT Review of Java Slide 45）
"White-box" reuse, since internal details of super classes are often visible to subclasses
“白盒”重用，因為超類的內部細節對子類通常是可見的

5）黑盒復用：
源代碼不可見，不能修改
– 只能通過API接口來使用，無法修改代碼
– 簡單，清晰
– 適應性差些

黑盒重用"Black-box" reuse（PPT Review of Java Slide 43）
"Black-box" reuse, since internal details of contained objects are not visible
因為包含對象的內部細節不可見

• 補充：
  組合(has-a)關系可以顯式地獲得被包含類（繼承中稱為父類）的對象，而繼承(is-a)則是隱式地獲得父類的對象，被包含類和父類對應，而組合外部類和子類對應。

組合關系是 局部類和整體類的關系
繼承關系 父類和子類的關系
(來源doc,網絡)

28.MVC模式
(來源DOC)
?MVC是 模型-視圖-控制器 的縮寫
它代表了一種軟件設計模式，1978年開發在施樂帕克研究中心(!)
它解釋了一種分離視覺、交互和數據組件的方法。
非常受歡迎,廣泛用于Java和其他語言

（百度百科）
Model（模型）是應用程序中用于處理應用程序數據邏輯的部分。
通常模型對象負責在數據庫中存取數據。
View（視圖）是應用程序中處理數據顯示的部分。
通常視圖是依據模型數據創建的。
Controller（控制器）是應用程序中處理用戶交互的部分。
通常控制器負責從視圖讀取數據，控制用戶輸入，并向模型發送數據。

模型 ：維護應用程序的狀態和數據的XML文檔
?“模型”包含的數據
?有一些方法來訪問并可能更新它的內容。
?通常,它實現了一個允許模型交互的接口。
?實現了一個允許退出和取代的接口，并不伴隨編程改變

視圖 ：XML文檔的呈現
?視圖提供模型的可視化表示。
?在任何時候都可以有多個視圖表示模型。
?例如,一個公司財務狀況隨著時間的推移可以用一個表和圖表示。
?只有兩種不同的視圖表示相同的數據。
?當模型更新時，所有視圖被通知然后有機會更新

控制器 ：用戶界面呈現給用戶操作的應用程序
?用戶與控制器進行交互。
?它解釋鼠標移動,點擊按鍵等
?活動與模型溝通，如:刪除行,插入行等
?它的模型的交互間接導致視圖的更新

2.png

29.企業應用架構有那三層，各層主要做什么。在各層有那些主要的模式，各層，各層的各種模式的定義和結構內容（展現層，領域層，數據源層）

（PPT ch9 slide 110）
1）表現層：提供服務，顯示信息。頁面控制器，模板視圖，前端控制器，轉換視圖。
2）領域層：領域邏輯，領域中真正的核心。也稱為業務邏輯，它是應用程序必須做的所有領域相關工作：包括根據輸入數據和已有數據進行計算，對從表現層輸入的數據進行驗證以及根據從表現層接受的命令來確定應該調試哪些數據源邏輯。事物腳本，領域模型，表模塊，活動記錄。
3）數據源層：與數據庫、系統消息系統、事務管理器及其他軟件包進行通信。最主要的數據源邏輯就是數據庫，主要責任是存儲持久數據。行數據網關，表數據網關，數據映射程序，表模塊，活動記錄。

30.4+1視圖

“4+1”視圖模型即從5個不同的視角（邏輯視圖，進程視圖，物理視圖，開發視圖
和場景視圖）來描述軟件體系結構。
每個視圖之關心系統的一個側面，5個視圖結合在一起才能反映系統的軟件體系結構的全部內容。

邏輯視圖（Logical View）：
過程視圖：描述架構元素之間的并發和通信
物理視圖：描繪主要的過程和組件是如何映像到硬件上的
開發視圖：俘獲軟件組件內部的結構，如配置管理工具

架構用例：俘獲架構的需求；和不止一種視圖相關

百度百科
邏輯視圖（Logical View）設計的對象模型（使用[面向對象]的設計方法時）。
過程視圖（Process View）捕捉設計的并發和同步特征。
物理視圖（Physical View）描述了軟件到硬件的映射，反映了分布式特性。
開發視圖（Development View）描述了在[開發環境]中軟件的靜態組織結構。

架構的描述，即所做的各種決定，可以圍繞著這四個視圖來組織，然后由一些用例 （use cases）或場景(scenarios)來說明，從而形成了第五個視圖。

3.png

來源DOC

31.應用的集成策略

2.png

• Data – expose application data for access by other components
  公開應用程序數據供其他組件訪問
• API – offers services to read/write application data through an abstracted interface
  即數據——公開應用程序數據訪問的其他組件，提供服務來讀/寫應用程序數據通過一個抽象接口

API（Application Programming Interface,應用程序編程接口）是一些預先定義的函數，目的是提供應用程序與開發人員基于某軟件或硬件得以訪問一組例程的能力，而又無需訪問源碼，或理解內部工作機制的細節。

來源DOC

補充內容：
1.一些指標

• Performance：Application performance must provide sub-four second response times for 90% of requests.
  性能:應用程序性能人工跑道跑四秒的響應時間必須提供90%的請求。
• Security: All communications must be authenticated and encrypted using certificates.
  安全性:所有通信都必須使用證書進行身份驗證和加密。
• Resource Management：The server component must run on a low end office-based server with 512MB memory.
  資源管理:服務器組件必須運行在一個低端辦公室服務器512 mb內存。
• Usability：The user interface component must run in an Internet browser to support remote users.
  可用性:用戶界面組件必須運行在一個網絡瀏覽器支持遠程用戶。
• Availability: The system must run 24x7x365, with overall availability of 0.99.
  有效性:系統必須運行24x7x365，總體可用性為0.99。
• Reliability：No message loss is allowed, and all message delivery outcomes must be known with 30 seconds
  可靠性:沒有信息損失是允許的,和所有的消息傳遞的結果必須是已知的30秒
• Scalability：The application must be able to handle a peak load of 500 concurrent users during the enrollment period.
  可伸縮性:應用程序必須能夠處理500個并發用戶的峰值負載在招生期間。
• Modifiability: The architecture must support a phased migration from the current Forth Generation Language (4GL) version to a .NET systems technology solution.
  可修改性:體系結構必須支持從當前的第四代語言(4GL)版本到. net系統技術解決方案的階段性遷移。