今天剛考完軟件體系結構，把考前的知識點總結髮到羣裏，僅供自己參考，但是裏面的內容確實有用也是面試會問到的基礎，所以這門課很重要的還是，只可惜我是預習了一兩天就參加考試了
對了我們的教材是《軟件工程體系結構原理、方法與實踐（第2版）》張友生 編著的
第一章
1. 軟件危機的表現： 軟件成本日益增長。開發進度難以控制。軟件質量差。軟件維護困難
2. 軟件危機的原因： 用戶需求不明確。缺乏正確的理論指導。軟件規模越來越大。軟件複雜度越來越高
3. 軟件工程的三要素： 方法，工具，過程
4. 構件概念： 構件是指語義完整、語法正確和有可重用價值的單位軟件，是軟件重用過程中可以明確辨識的系統；結構上，它是語義描述、通訊接口和實現代碼的複合體
5. 常見的構件模型： OMG的CORBA。Sun的EJB。Microsoft的DCOM（分佈式構件對象模型）
6. 構件分類方法： 關鍵字分類法。刻面分類法。超文本組織方法。
7. 軟件體系結構的定義： 軟件體系結構爲軟件系統提供了一個結構、行爲和屬性的高級抽象，由構成系統的元素的描述、這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成。 （軟件體系結構不僅指定了系統的組織結構和拓撲結構，並且顯示了系統需求和構成系統的元素之間的對應關係，提供了一些設計決策的基本原理）
8. 軟件體系結構的意義： 1體系結構是風險承擔者進行交流的手段 2 體系結構是早期設計決策的體現 3軟件體系結構是可傳遞和可重用的模型
第二章：
1.軟件體系結構模型及功能：
結構模型：以體系結構的構件、連接件和其他概念來刻畫結構，併力圖通過結構來反映系統的重要語義內容，包括系統的配置、約束、隱含的假設條件、風格、性質等。
框架模型：側重於整體的結構。主要以一些特殊的問題爲目標建立只針對和適應該問題的結構。
動態模型：是對結構或框架模型的補充，研究系統的“大顆粒”的行爲性質。例如，描述系統的重新配置或演化。動態可以指系統總體結構的配置、建立或拆除通信通道或計算的過程。
過程模型：過程模型研究構造系統的步驟和過程。
功能模型：認爲體系結構是由一組功能構件按層次組成，下層向上層提供服務。可以看作是一種特殊的框架模型。
2.“4+1”視圖模型及功能作用：
邏輯視圖：主要支持系統的功能需求，即系統提供給最終用戶的服務。在邏輯視圖中，系統分解成一系列的功能抽象，這些抽象主要來自問題領域。這種分解不但可以用來進行功能分析，而且可用作標識在整個系統的各個不同部分的通用機制和設計元素。在面向對象技術中，通過抽象、封裝和繼承，可以用對象模型來代表邏輯視圖，用類圖來描述邏輯視圖。
開發視圖：也稱模塊視圖，主要側重於軟件模塊的組織和管理。開發視圖要考慮軟件內部的需求，如軟件開發的容易性、軟件的重用和軟件的通用性，要充分考慮由於具體開發工具的不同而帶來的侷限性。開發視圖通過系統輸入輸出關係的模型圖和子系統圖來描述。
進程視圖：側重於系統的運行特性，主要關注一些非功能性的需求。進程視圖強調併發性、分佈性、系統集成性和容錯能力，以及從邏輯視圖中的主要抽象如何適合進程結構。它也定義邏輯視圖中的各個類的操作具體是在哪一個線程中被執行的。進程視圖可以描述成多層抽象，每個級別分別關注不同的方面。在最高層抽象中，進程結構可以看作是構成一個執行單元的一組任務。它可看成一系列獨立的，通過邏輯網絡相互通信的程序。它們是分佈的，通過總線或局域網、廣域網等硬件資源連接起來。
物理視圖：主要考慮如何把軟件映射到硬件上，它通常要考慮到系統性能、規模、可靠性等。解決系統拓撲結構、系統安裝、通訊等問題。當軟件運行於不同的節點上時，各視圖中的構件都直接或間接地對應於系統的不同節點上。因此，從軟件到節點的映射要有較高的靈活性，當環境改變時，對系統其他視圖的影響最小。
場景視圖：可以看作是那些重要系統活動的抽象，它使四個視圖有機聯繫起來，從某種意義上說場景是最重要的需求抽象。在開發體系結構時，它可以幫助設計者找到體系結構的構件和它們之間的作用關係。同時，也可以用場景來分析一個特定的視圖，或描述不同視圖構件間是如何相互作用的。場景可以用文本表示，也可以用圖形表示。
3.核心模型的基本元素：構件、連接件、配置、端口、角色。
4.生命週期模型階段：
軟件體系結構的非形式化描述階段；規範描述和分析階段；求精及其驗證；實施；演化和擴展；提供評價和度量；終結；
第三章
9.軟件體系結構風格是什麼？ 是描述某一特定應用領域中系統組織方式的慣用模式
10.經典的軟件體系結構風格有哪些？
1 數據流風格：批處理序列；管道/過濾器
2 調用/返回風格：主程序/子程序；面向對象風格；層次結構
3 獨立構件風格：進程通訊；事件系統
4 虛擬機風格：解釋器；基於規則的系統
5 倉庫風格：數據庫系統；超文本系統；黑板系統
11.C/S（客戶-服務器）風格定義： C/S軟件體系結構是基於資源不對等，且爲實現共享而提出來的。它定義了工作站如何與服務器相連，以實現數據和應用分佈到多個處理機上。有三個主要組成部分：數據庫服務器、客戶應用程序和網絡。
C/S風格優點：
- 具有強大的數據操作和事務處理能力，模型思想簡單，易於人們理解和接受
- 系統的客戶應用程序和服務器構件分別運行在不同的計算機上，系統中每臺服務器都可以適合各構件的要求，這對於硬件和軟件的變化顯示出極大的適應性和靈活性，而且易於對系統進行擴充和縮小
- 在C/S體系結構中，客戶應用程序的開發集中於數據的顯示和分析，而數據庫服務器的開發則集中於數據的管理，不必在每一個新的應用程序中都要對一個DBMS進行編碼。將大的應用處理任務分佈到許多通過網絡連接的低成本計算機上，以節約大量費用
缺點：開發成本較高。客戶端程序設計複雜。信息內容和形式單一。用戶界面風格不一，使用繁雜，不利於推廣使用。軟件移植困難。軟件維護和升級困難。新技術不能輕易應用。
12.三層C/S風格： 三層：表示層，功能層，數據層。
優點：1 允許合理地劃分三層結構的功能，使之在邏輯上保持相對獨立性，能提高系統和軟件的可維護性和可擴展性 2 允許更靈活有效地選用相應的平臺和硬件系統，使之在處理負荷能力上與處理特性上分別適應於結構清晰的三層；並且這些平臺和各個組成部分可以具有良好的可升級性和開放性 3 應用的各層可以並行開發，可以選擇各自最適合的開發語言 4 利用功能層有效地隔離開表示層與數據層，未授權的用戶難以繞過功能層而利用數據庫工具或黑客手段去非法地訪問數據層，爲嚴格的安全管理奠定了堅實的基礎
缺點：1 三層C/S結構各層間的通信效率若不高，即使分配給各層的硬件能力很強，其作爲整體來說也達不到所要求的性能 2 設計時必須慎重考慮三層間的通信方法、通信頻度及數據量。這和提高各層的獨立性一樣是三層C/S結構的關鍵問題
13．B/S風格（瀏覽/服務器）： 就是三層C/S應用結構的一種實現方式，其具體結構爲：瀏覽器/Web服務器/數據庫服務器
優點：1 基於B/S體系結構的軟件，系統安裝、修改和維護全在服務器端解決。用戶在使用系統時，僅僅需要一個瀏覽器就可運行全部的模塊，真正達到了“零客戶端”的功能，很容易在運行時自動升級 2 還提供了異種機、異種網、異種應用服務的聯機、聯網、統一服務的最現實的開放性基礎
缺點：1 B/S體系結構缺乏對動態頁面的支持能力，沒有集成有效的數據庫處理功能 2系統擴展能力差，安全性難以控制 3 在數據查詢等響應速度上，要遠遠地低於C/S體系結構 4 數據提交一般以頁面爲單位，數據的動態交互性不強，不利於在線事務處理(OLTP)應用
14.HMB風格（基於層次消息總線的體系結構風格）： HMB風格基於層次消息總線/支持構件的分佈和併發，構件之間通過消息總線進行通信。 消息總線是系統的連接件，負責消息的分派、傳遞和過濾以及處理結果的返回。各個構件掛接在消息總線上，向總線登記感興趣的消息類型。構件根據需要發出消息,由消息總線負責把該消息分派到系統中所有對此消息感興趣的構件，消息是構件之間通信的唯-方式。構件接收到消息後,根據自身狀態對消息進行響應,並通過總線返回處理結果。由於構件通過總線進行連接,並不要求各個構件具有相同的地址空間或侷限在一臺機器上。
15.HMB風格的消息總線的功能有哪些？ 1 消息登記 2 消息分派和傳遞 3 消息過濾
第五章
1. *UML中的關係：*
依賴，關聯，泛化，實現。
2. *類之間的關係：*
關聯，依賴，泛化，聚合，組合，實現，流關係。
3 . UML畫法
*第六章：*
XML概念： XML是一套定義語義標記的規則，這些標記將文檔分成許多部件並對這些部件加以標識。它也是元標記語言，用於定義其他與特定領域有關的，語義的，結構化的標記語言的句法語言。
第八章：
1. *SOA定義：*
SOA是一種應用程序體系結構，在這種體系結構中，所有功能都定義爲獨立的服務，這些服務帶有定義明確的可調用接口，能夠以定義好的順序調用這些服務來形成業務流程。
2. *SOA特徵：*
鬆散耦合、粗粒度服務、標準化接口
3. *SOA設計原則：*
明確定義的接口；自包含和模塊化；粗粒度；松耦合；互操作性、兼容和策略聲明
4. *SOA關鍵技術：*
服務棧 主要技術
| 發現服務層 | UDDI、DISCO |
|---|---|
| 描述服務層 | WSDL、XML Schema |
| 消息格式層 | SOAP、REST |
| 編碼格式層 | XML |
| 傳輸協議層 | HTTP、TCP/IP、SMTP等 |
*每一層的作用：*
發現服務層：用來幫助客戶端應用程序解析遠程服務的位置，通過UDDI來實現。
描述服務層：爲客戶端應用程序提供正確的與遠程服務交互的描述信息，通過WSDL來實現
消息格式層：用來保證客戶端應用程序和服務器端在格式設置上保持一致，通過SOAP實現
編碼層：主要爲客戶端和服務器之間提供一個標準的，獨立於平臺的數據交換編碼格式。通過XML實現。
傳輸層：爲客戶端和服務器之間提供兩者交互的網絡通信協議，通過HTTP和SMTP實現
5.SOAP應用： HTTP、RPC
6.SOAP 包含幾部分？ （1）SOAP封裝。****定義一個整體框架，用來表示消息中包含什麼內容，誰來處理這些內容，以及這些內容是可選的或是必需的 （2）****SOAP編碼規則****。定義了一種序列化的機制，用於交換系統所定義的數據類型的實例 （3）****SOAP RPC表示。****定義一個用來表示遠程過程調用和應答的協議 （****4）SOAP綁定****。定義一個使用底層傳輸協議來完成在節點間交換SOAP信封的約定
第十二章
1. 設計模式：（下邊兩種表述都可以）
設計模式是軟件開發人員在軟件開發過程中面臨的一般問題的解決方案。這些解決方案是衆多軟件開發人員經過相當長的一段時間的試驗和錯誤總結出來的。
描述了一個出現在特定設計語境中的特殊的再現設計問題，併爲它的解決方案提供了一個經過充分驗證的通用圖示。
2. 設計模式的組成：
模式名稱、問題、解決方案、後果 。
3. 設計模式的分類：
創建型模式：工廠方法模式，抽象工廠模式，原型模式，單例模式，構建器模式；
結構型模式：適配器模式、橋接模式、組合模式、裝飾模式、外觀模式，享元模式，代理模式；
行爲型模式：職責鏈模式，命令模式，解釋器模式，迭代器模式，中介者模式，備忘錄模式， 觀察者模式，狀態模式，策略模式，模板方法模式，訪問者模式
4. MVC與SpringMVC：
（1）MVC是什麼？
MVC是模型(model)－視圖(view)－控制器(controller)的縮寫，是一種軟件設計典範。它是用一種業務邏輯、數據與界面顯示分離的方法來組織代碼，將衆多的業務邏輯聚集到一個部件裏面，在需要改進和個性化定製界面及用戶交互的同時，不需要重新編寫業務邏輯，達到減少編碼的時間。
（2）MVC構成：
Model：封裝領域數據及邏輯
View：查詢領域數據並展現給用戶
Conctroller：截獲用戶請求並改變領域數據
（2）SpringMVC分層：
實體類也是POJO類，也就是MVC的數據模型，實體類僅有屬性以及獲取和設置屬性的get和set方法，沒有事務處理方法。
DAO負責數據訪問
Service業務層主要用來處理業務邏輯
Controller層負責具體的業務模塊流程的控制，在此層裏面要調用Serice層的接口來控制業務流程。
（4）IOC“控制反轉”：藉助於“第三方”實現具有依賴關係的對象之間的解耦。一種將控制權轉移的設計模式，由傳統的程序控制轉移到容器控制。
（5）DI依賴注入：就是由IOC容器在運行期間，動態地將某種依賴關係注入到對象之中。常用的有兩種方式：構造方法注入和setter方法注入。
5. 單例模式：
保證一個類只有一個實例，並提供一個訪問它的全局訪問點
SingleObject 類提供了一個靜態方法，供外界獲取它的靜態實例。SingletonPatternDemo，我們的演示類使用 SingleObject 類來獲取SingleObject 對象。
| public class SingleObject { //創建 SingleObject 的一個對象 private static SingleObject instance = new SingleObject(); //讓構造函數爲 private，這樣該類就不會被實例化 private SingleObject(){} //獲取唯一可用的對象 public static SingleObject getInstance(){ return instance; } public void showMessage(){ System.out.println(“Hello World!”); } } |
|---|
| public class SingletonPatternDemo { public static void main(String[] args) { //獲取唯一可用的對象 SingleObject object = SingleObject.getInstance(); //顯示消息 object.showMessage(); } } |
public class SingleObject {
//創建 SingleObject 的一個對象
private static SingleObject instance = new SingleObject();
//讓構造函數爲 private，這樣該類就不會被實例化
private SingleObject(){}
//獲取唯一可用的對象
public static SingleObject getInstance(){
return instance;
}
public void showMessage(){
System.out.println("Hello World!");
}
}
public class SingletonPatternDemo {
public static void main(String[] args) {
//獲取唯一可用的對象
SingleObject object = SingleObject.getInstance();
//顯示消息
object.showMessage();
}
}
- 抽象工廠模式：
提供一個接口，可以創建一系列相關或相互依賴的對象，而無需指定它們具體的類
AbstractFactory：抽象工廠，聲明抽象產品的方法
ConcreteFactory：具體工廠，執行生成抽象產品的方法，生成一個具體的產品
AbstractProduct：抽象產品，爲一種產品聲明接口
Product：具體產品，定義具體工廠生成的具體產品的對象，實現產品接口
Client：客戶，應用程序使用抽象產品和抽象工廠生成對象
/* 抽象工廠的抽象類，Java定義爲接口*/
public interface AbstractFactory {
//創建產品的方法
public AbstractProductA CreateProductA();
public AbstractProductB CreateProductB();
}
/*抽象產品接口*/
public interface AbstractProductA {
}
public interface AbstractProductB {
}
/*實際的產品*/
public class ProductA1 implements AbstractProductA {
//實際的產品A1
}
public class ProductA2 implements AbstractProductA {
//實際的產品A2
}
public class ProductB1 implements AbstractProductB {
//實際的產品B1
}
public class ProductB2 implements AbstractProductB {
//實際的產品B2
}
/*在以下程序中，CFactory是ConcreteFactory的簡寫*/
/*在第1個車間中，創建實際產品A1*/
public class CFactory1 implements AbstractFactory {
public AbstractProductA CreateProductA() {
return new ProductA1();
}
}
/*在第1個車間中，創建實際產品B1*/
public class CFactory1 implements AbstractFactory {
public AbstractProductB CreateProductB() {
return new ProductB1();
}
}
/*在第2個車間中，創建實際產品A2*/
public class CFactory2 implements AbstractFactory {
public AbstractProductA CreateProductA() {
return new ProductA2();
}
}
/*在第2個車間中，創建實際產品B2*/
public class CFactory2 implements AbstractFactory {
public AbstractProductB CreateProductB() {
return new ProductB2();
}
}
- 觀察者模式：
定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並自動更新
抽象主題（Subject）角色：也叫抽象目標類，它提供了一個用於保存觀察者對象的聚集類和增加、刪除觀察者對象的方法，以及通知所有觀察者的抽象方法。
具體主題（Concrete Subject）角色：也叫具體目標類，它實現抽象目標中的通知方法，當具體主題的內部狀態發生改變時，通知所有註冊過的觀察者對象。
抽象觀察者（Observer）角色：它是一個抽象類或接口，它包含了一個更新自己的抽象方法，當接到具體主題的更改通知時被調用。
具體觀察者（Concrete Observer）角色：實現抽象觀察者中定義的抽象方法，以便在得到目標的更改通知時更新自身的狀態。
import java.util.*;
public class ObserverPattern
{
public static void main(String[] args)
{
Subject subject=new ConcreteSubject();
Observer obs1=new ConcreteObserver1();
Observer obs2=new ConcreteObserver2();
subject.add(obs1);
subject.add(obs2);
subject.notifyObserver();
}
}
//抽象目標
abstract class Subject
{
protected List<Observer> observers=new ArrayList<Observer>();
//增加觀察者方法
public void add(Observer observer)
{
observers.add(observer);
}
//刪除觀察者方法
public void remove(Observer observer)
{
observers.remove(observer);
}
public abstract void notifyObserver(); //通知觀察者方法
}
//具體目標
class ConcreteSubject extends Subject
{
public void notifyObserver()
{
System.out.println("具體目標發生改變...");
System.out.println("--------------");
for(Object obs:observers)
{
((Observer)obs).response();
}
}
}
//抽象觀察者
interface Observer
{
void response(); //反應
}
//具體觀察者1
class ConcreteObserver1 implements Observer
{
public void response()
{
System.out.println("具體觀察者1作出反應！");
}
}
//具體觀察者1
class ConcreteObserver2 implements Observer
{
public void response()
{
System.out.println("具體觀察者2作出反應！");
}
}
- 組合模式：
將對象組合成樹型結構以表示“整體-部分”的層次結構，使得用戶對單個對象和組合對象的使用具有一致性
我們有一個類 Employee，該類被當作組合模型類。CompositePatternDemo，我們的演示類使用 Employee 類來添加部門層次結構，並打印所有員工。
import java.util.ArrayList;
import java.util.List;
public class Employee {
private String name;
private String dept;
private int salary;
private List<Employee> subordinates;
//構造函數
public Employee(String name,String dept, int sal) {
this.name = name;
this.dept = dept;
this.salary = sal;
subordinates = new ArrayList<Employee>();
}
public void add(Employee e) {
subordinates.add(e);
}
public void remove(Employee e) {
subordinates.remove(e);
}
public List<Employee> getSubordinates(){
return subordinates;
}
public String toString(){
return ("Employee :[ Name : "+ name
+", dept : "+ dept + ", salary :"
+ salary+" ]");
}
}
import java.util.ArrayList;
import java.util.List;
public class Employee {
private String name;
private String dept;
private int salary;
private List<Employee> subordinates;
//構造函數
public Employee(String name,String dept, int sal) {
this.name = name;
this.dept = dept;
this.salary = sal;
subordinates = new ArrayList<Employee>();
}
public void add(Employee e) {
subordinates.add(e);
}
public void remove(Employee e) {
subordinates.remove(e);
}
public List<Employee> getSubordinates(){
return subordinates;
}
public String toString(){
return ("Employee :[ Name : "+ name
+", dept : "+ dept + ", salary :"
+ salary+" ]");
}
}
9. 中間件概念：
中間件是一種獨立的系統軟件或服務程序，分佈式應用軟件藉助這種軟件在不同的技術之間共享資源，中間件位於操作系統之上，管理計算資源和網絡通信，實現應用之間的互操作。
10. 中間件功能：
(1) 負責客戶機與服務器之間的連接和通信，以及客戶機與應用層之間的高效率通信機制。
(2) 提供應用層不同服務之間的互操作機制，以及應用層與數據庫之間的連接和控制機制。
(3) 提供一個多層體系結構的應用開發和運行的平臺，以及一個應用開發框架，支持模塊化的應用開發。
(4) 屏蔽硬件、操作系統、網絡和數據庫的差異。
(5) 提供應用的負載均衡和高可用性、安全機制與管理功能，以及交易管理機制，保證交易的一致性。
(6) 提供一組通用的服務去執行不同的功能，避免重複的工作和使應用之間可以協作。
11. 消息中間件定義和使用場景：
（1）定義：消息中間件屬於分佈式系統中一個子系統，關注於數據的發送和接收，利用高效可靠的消息傳遞機制進行平臺無關的數據交流，並基於數據通信來進行分佈式系統的集成。通過提供消息傳遞和消息排隊模型，它可以在分佈式環境下擴展進程間的通信。
（2）使用場景：
四個典型場景：典型的異步處理、應用解耦、流量削鋒、消息通訊四個場景。
舉例：秒殺活動，一般會因爲流量過大，導致流量暴增，應用掛掉。爲解決這個問題，一般需要在應用前端加入消息隊列。（流量削鋒）
11.常用消息中間件：
ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。
12.I/O模型：
（1）阻塞I/O模型：進程或線程等待某個條件，如果條件不滿足，則一直等下去。條件滿足，則進行下一步操作。
（2）非阻塞I/O模型：應用進程與內核交互，目的未達到時，不再一味的等着，而是直接返回。然後通過輪詢的方式，不停的去問內核數據準備好沒。
（3）I/O 複用模型
一個進程能同時等待多個文件描述符，而這些文件描述符（套接字描述符）其中的任意一個進入讀就緒狀態，select()函數就可以返回。
（4）信號驅動式 I/O 模型
首先開啓Socket信號驅動I/O功能，並通過系統調用sigaction執行一個信號處理函數（此係統調用立即返回，進程繼續工作，它是非阻塞的）。當數據準備就緒時，就爲進程生成一個SIGIO信號，通過信號會掉通知應用程序調用recvfrom來讀取數據，並通知主循環函數來處理數據。
（5）異步 I/O 模型
告知內核啓動某個操作，並讓內核在整個操作完成後（包括將數據從內核複製到用戶自己的緩衝區）通知開發者。
第十一章
1. *軟件質量屬性：*
性能、可靠性（容錯，健壯性），可用性，安全性，可修改性（可維護性，可擴展性，結構重組，可移植性），功能性，可變性，繼承性，互操作性。
2. *評估的主要方式：*
基於調查問卷或檢查表的評估方式，基於場景的評估方式，基於度量的評估方式
3. *ATAM評估步驟：*
描述ATAM方法；描述業務動機；描述架構；確定架構方法；生成質量屬性效用樹；分析架構方法；討論場最和對場景分級.；分析架構方法；描述評估結果。
4. *SAAM評估步驟：*
形成場景、描述體系結構、對場景進行分類和確定優先級、對間接場景進行單個評估、評估場景的相互作用、形成總體評價
第十三章
1.軟件產品線定義：產品線是一個產品集合，這些產品共享一個公共的、可管理的特徵集，這個特徵集能滿足選定的市場或任務領域的特定需求。這些系統遵循一個預描述的方式，在公共的核心資源基礎上開發的
檢查表的評估方式，基於場景的評估方式，基於度量的評估方式
3. *ATAM評估步驟：*
描述ATAM方法；描述業務動機；描述架構；確定架構方法；生成質量屬性效用樹；分析架構方法；討論場最和對場景分級.；分析架構方法；描述評估結果。
4. *SAAM評估步驟：*
形成場景、描述體系結構、對場景進行分類和確定優先級、對間接場景進行單個評估、評估場景的相互作用、形成總體評價
第十三章
1.軟件產品線定義：產品線是一個產品集合，這些產品共享一個公共的、可管理的特徵集，這個特徵集能滿足選定的市場或任務領域的特定需求。這些系統遵循一個預描述的方式，在公共的核心資源基礎上開發的