體系結構概要
1.軟件開發知識的半衰期 為3年
2.支持軟件工程的根基在於質量關注點
• 軟件工程過程和實踐的通用原則主要是：
– ① 為最終用戶提供價值，
– ② 保持簡潔，
– ③ 維護可見的東西（產品和計划），
– ④ 認識（必須理解別人將消費你所生產的產品），
– ⑤ 面向未來，
– ⑥ 計划復用，以及
⑦ 認真思考
3. 關於軟件工程原則
指導實踐的核心原則：（1）指導過程的原則、（2）指導實踐的原則
指導框架活動的原則：溝通原則、策划原則、建模原則、構造原則、部署原則
建模原則：1.敏捷模型建模原則、2. 需求建模原則、3. 設計建模原則
4. 軟件的三個設計層次：體系結構級，代碼級，執行級
\5. 軟件體系結構的定義
（1）Dewayne Perry和A1ex Wolf這樣定義：軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連接構件。處理構件負責對數據進行加工，數據構件是被加工的信息，連接構件把體系結構的不同部分組合連接起來。這一定義注重區分構件，這一方法在其他的定義和方法中基本上得到保持。
\6. 在體系結構的層次上，相關的系統級別的問題包括了容量、吞吐量、一致性、構件的兼容性等。
7.體系結構的設計原則： 1.抽象原則 2.分而治之 3.封裝和信息隱蔽原則 4.模塊化原則 5.高內聚低耦合 5.關注點分離 6.策略和實現分離策略 7.接口和實現分離原則
\8. 請解釋需求工程
需求工程（Requirement Engineering，RE）是指致力於不斷理解需求的大量任務和技術。從軟件過程的角度來看，需求工程發生在與客戶溝通活動和為一般的軟件過程定義的建模活動過程中，其任務是為設計和構建活動建立一個可靠堅固的基礎，它必須適應過程、項目、產品和人員工作的需要。需求工程在設計和構造之間建立起聯系的橋梁。
9．需求工程過程通過執行七個不同的活動來實現：起始、導出、精化、協商、規格說明，確認和管理，其中起始、導出和精化屬於項目的起始階段
下面這組問題有助於理解為什么導出需求這么困難：
范圍問題：理解問題：易變問題。
10. 軟件需求規格說明（SRS）是在項目商業化之前必須建立詳細描述軟件各個方面的文檔。
11. 質量功能部署（Quality Function Deployment，QFD）是一種將客戶要求轉化成軟件技術需求的質量管理技術，其目的是“最大限度地讓客戶從軟件工程過程中感到滿意 ”。
12. QFD 確認三類需求：
正常需求。期望需求，令人興奮的需求。
13. 需求建模活動產生以下一種或多種模型類型：場景 模型，數據模型，面向流程的模，行為模型，分析模型，軟件域分析。
14. 類-職責-協作者（Class-Responsibility-Collaborator，CRC）建模提供了一個簡單方法，可以識別和組織與系統或產品需求相關的類。
在結構化分析中，面向數據流建模仍然是當前使用最廣泛的需求分析表達方式之一。
15. 需求模型由各種元素組成：基於場景（用例）、基於數據（數據模型）、基於類、基於流和行為。
16. 這些交互模型描述會話，這種交互模型由常用幾種元素組成：① 用例；② 順序圖；③ 狀態圖；④ 用戶界面原型。
17. 軟件質量屬性有哪些？
代表功能性（functionality）、易用性（usability）、可靠性（reliability）、性能（performance）、可支持性（supportability）
18. 軟件設計中關注點有常用幾種不同的信息分類：
1．功能性關注點 2. 服務質量關注點 3.政策 關注點 4.系統關注點 5.機構關注點
19．軟件體系結構意指“軟件的整體結構和這種結構為系統提供概念完整性的方式”。
20. 下面這組屬性應該被指定為體系結構設計的一部分：
結構特性。體系結構設計表示定義了系統的構件（如模塊、對象、過濾器）、構件被封裝的方式以及構件之間相互作用的方式。例如，對象封裝了數據和過程，過程操縱數據並通過方法調用進行交互。
外部功能特性。體系結構設計描述應當指出設計體系結構如何滿足需求這些需求包括性能需求、能力需求、可靠性需求、安全性需求、可適應性需求以及其他系統特征需求。
相關系統族。體系結構應當能抽取出在一類相似系統開發中經常遇到的重復性模式。本質上，設計應當能夠重用體系結構構件。
設計模式描述了在某個特定場景與可能影響模式應用和使用方式的“影響力”中解決某個特定的設計問題的設計結構。
信息隱蔽原則建議模塊應該“具有的特征是：每個模塊對其他所有模塊都隱蔽自己的設計決策”。
功能獨立的概念是關注點分離、模塊化、抽象和信息隱蔽概念的直接產物。
內聚性顯示了某個模塊相關功能的強度，是信息隱蔽概念的自然擴展。
耦合性顯示了模塊間的相互依賴性，它表明軟件結構中多個模塊之間的相互連接性。
耦合性依賴於模塊之間的接口復雜性、引用或進入模塊所在的點以及什么數據通過接口進行傳遞。
通過連續精化過程細節層次來實現程序的開發，通過逐步分解功能的宏觀陳述（過程抽象）直至形成程序設計語言的語句來進行層次開發。
抽象能夠明確說明內部過程和數據，但對“外部使用者”隱藏了低層細節；精化有助於在設計過程中揭示低層細節。這兩個概念均有助於設計人員在設計演化中構造出完整的設計模型。
重構是使用這樣一種方式改變軟件系統的過程：不改變代碼（設計）的外部行為而是改進其內部結構。
21. 有五種不同類型的設計類，每一種都表示了設計體系結構的一個不同層次：
用戶接口類：定義人-機交互（Human-Computer Interaction, HCI）所必需的所有抽象。在很多情況下，HCI出現在隱喻的環境（例如，支票簿、訂單表格、傳真機），而接口的設計類可能是這種隱喻元素的可視化表示。
業務域類：通常是早期定義的分析類的精化。這些類識別實現某些業務域元素所必需的屬性和服務（方法）。
過程類：實現完整的管理業務域類所必需的低層業務抽象。
持久類：表示將在軟件執行之外持續存在的數據存儲（例如，數據庫）。
系統類：實現軟件管理和控制功能，使得系統能夠運行，並在其計算環境內與外界通信。
22.組織良好的設計類具有4個基本特征： 完整性與充分性，關注於實現類的某一服務，高內聚，低耦合
23. 接口設計有3個重要的元素：① 用戶界面（UI）；② 和其他系統、設備、網絡或其他信息生成者或使用者的外部接口；③ 各種設計構件之間的內部接口。
24. 4種基礎的體系結構視圖是：
1）邏輯視圖。顯示了系統中對象和對象類的一些主要抽象。通過邏輯視圖，可以將系統需求和實體關聯起來。
2）進程視圖。顯示了在運行時系統是如何組織為一組交互的進程。這種視圖對非功能系統特征的判斷非常有效，比如性能和可用性。
3）開發視圖。顯示了軟件是如何為了開發而被分解的，即將軟件分解成可以由單獨的開發人員或開發團隊實現的組件。這種視圖主要用於軟件的管理者和程序員。
4）物理視圖。顯示了系統硬件和系統中軟件組件是如何分布在處理器上的。這種視圖對系統工程師規划系統部署非常有用。
25．5種典型的基本體系結構（構件、連接件和特性）是：
1．功能結構 2.實現結構 3.並發結構 4.物理結構 5.開發結構
26. 應用較多的體系結構模式有：MVC（模型-視圖-控制器）、批處理序列、管道-過濾器（數據流）、調用和返回、主程序和子程序、面向對象系統、多級分層、客戶機-服務器、獨立構件、通信進程、事件系統、虛擬機、解釋器、基於規則系統、數據中心系統（知識庫、黑板、容器）、數據庫、超文本系統、過程控制。
27. 黑板模型通常由三個部分組成：
l）知識源：分離的，獨立的，依賴於應用的知識包。知識源僅通過黑板進行交互。
2）黑板數據結構：問題求解狀態數據，被組織成依賴於應用的層次結構。知識源不斷修改黑板中的數據，直到問題得解。
3）控制器：完全由黑板的狀態驅動。一旦黑板的狀態使某個知識源可用，知識源就會適時地響應。
28. 應用框架（Application Framework）是整個或部分系統的可重用設計，表現為一組抽象構件的集合以及構件實例間交互的方法。
29. 事務處理系統（Transaction processing systems，TPS）是設計用來處理用戶對數據庫信息的查詢或者對數據庫的更新，允許數據庫中的信息被很多遠程用戶訪問和修改。
30. 語言處理系統用來將文本從一種語言翻譯成另一種語言，例如把自然語言或人工語言翻譯成該類語言的其他表示，對於編程語言可能會執行產生的代碼，來執行輸入語言所定義的指令。它們包括一個翻譯器和一個執行生成的語言的抽象機。
31. 非功能性需求和軟件體系結構的密切關系，我們為系統所選擇的特殊的體系結構風格和結構應當依賴於哪些非功能性系統需求：
（1）性能。
（2）信息安全性。
（3）系統安全性。
（4）可用性。
（5）可維護性。
32. 原型（archetype）是體系結構設計的抽象構造塊，是表示核心抽象的類或模式，該抽象對於目標系統體系結構的設計非常關鍵。
33. 在SafeHome住宅安全功能的例子中，可以定義完成下列功能的頂層構件集合：
外部通信管理——協調安全功能與外部實體（如基於因特網的系統與外部報警通知）的通信；
控制面板處理——管理所有的控制面板功能；
探測器管理——協調對系統所有探測器的訪問；
警報處理——審核所有報警條件並執行相應動作。
34. 用UML進行設計通常需要如下兩類設計模型：
（1）結構（靜態）模型。通過系統對象類及其之間的關系來描述系統的靜態結構。在這一階段需要記錄的重要關系有泛化（繼承）關系、使用/被使用關系和組成關系。
（2）動態模型。描述系統的動態結構和系統對象之間的交互。需要記錄的交互包括由對象發出的服務請求序列以及由這些對象交互觸發的狀態變化。
35. 在設計過程的早期階段，有3個模型特別有助於為用例和體系結構模型增加細節，即：
1.子系統模型 2.時序模型 3.狀態機模型
36. 設計模式的4種主要元素是：
1）名字，是模式的一個有意義的指代。
2）問題域的描述，解釋什么時候模式可以應用。
3）對部分設計的解決方案描述，描述設計方案的各個部分及其之間的關系和職責。模式可以用不同的方式實例化，通常以圖形方式表達，示意出解決方案中對象及對象類間的關系。
4）結果陳述，說明應用該模式的結果和副作用。用來幫助設計者了解是否一個模式在特定環境條件下是有效的。
37 .軟件復用的不通層次：
1. 抽象層次 2， 對象層次 3 . 組件層次 4.系統層次
38. 配置管理包含如下3個基本活動：
（1）版本管理，對軟件組件不同版本的追蹤提供支持。版木管理系統包括協調多個程序員開發的機制，可以防止一個程序員覆蓋其他人提交到系統中的代碼。
（2）系統集成，即提供支持幫助開發人員定義在創建每個系統版本時所用的組件版本。這些描述可以用於編譯連接需要的組件以自動構建一個系統。
（3）問題追蹤，即提供支持允許用戶報告缺陷及其他問題，並允許開發人員查看誰在修復這些問題，以及何時完成的修復。
39. 傳統構件也稱為模塊，作為軟件體系結構的一部分，它承擔如下3個重要角色之一：
① 控制構件，協調問題域中所有其他構件的調用；
② 問題域構件，實現客戶需要的全部功能或部分功能；
③ 基礎設施構件，負責完成問題域中所需支持處理的功能。
40. 構件級設計的基本設計原則，這些原則在使用面向對象軟件工程方法時被廣泛采用。
（1）開閉原則（The Open-Closed Principle, OCP）。
（2）Liskov替換原則（Liskov Substitution Principle, LSP）。“子類可以替換它們的基類”。
（3）依賴倒置原則（Dependency Inversion Principle, DIP）。“依賴於抽象，而非具體實現”。
4）接口分離原則（Interface Segregation Principle, ISP）。“多個客戶專用接口比一個通用接口要好”。
41． 類聚的幾個層次： 功能內聚 分層類聚 通信內聚
42. 基於構件的軟件工程（Component-Based Software Engineering, CBSE）是一種強調使用可復用的軟件構件來設計與構造計算機系統的過程。
43. CBSE把重點從編碼轉移到組裝軟件系統。考慮的焦點是“集成”而不再是“實現”
44. 領域工程包括3種主要活動：分析、構造和傳播。
45. 構成可復用設計基礎的一系列關鍵問題包括：
標准數據。應該仔細研究應用領域，並定義標准的全局數據結構（例如，文件結構或完整的數據庫）。然后，所有的設計構件會被賦予使用這些標准數據結構的特性。
標准接口協議。應該建立3層接口協議：模塊內部接口的基本屬性，外部技術（非人）接口設計和人機接口設計。
程序模板。選取一種體系結構風格，可以作為新軟件體系結構設計的模板。
可以用很多方式來描述可復用軟件構件，但是理想的描述包括所謂的3C模型，即概念（concept）、內容（content）和環境（context）。
46. 有3種與面向對象設計相關的設計模式，即創建型模式、結構型模式及行為型模式。
1.設計模式比框架更抽象
2.設計模式是比框架跟小的體系結構元素
3.對設計模式比對框架要少
47. 為找到所需要的模式，主要取決於以下4個方面的有效交流，即模式要解決的問題，模式所在的環境，影響環境的因素及所提出的解決方案。
48. 根據粒度的級別，模式可以按下面的級別描述：
體系結構模式。這個抽象級別通常與定義WebApp總體結構的模式有關，表示不同構件或增量間的關系，為指定體系結構元素（網頁、包、構件、子系統）間的關系定義規則。
設計模式。設計模式處理特定的設計元素（例如構件的聚合）來解決一些設計問題，網頁上元素間的關系，或影響構件間通信的機制。例如，Broadsheet模式可用於WebApp主頁的布局。
構件模式。這個抽象級別與WebApp的個別小規模元素有關。這方面的例子有：個別交互元素（例如，單選按鈕），導航元素（例如，如何格式化鏈接）或功能性元素（例如特定算法）。
49 WebAPP質量需求樹
.
50.根據WebApp性質的不同而適當地混合各種技術，用WebApp設計金字塔來各層技術關系。
\51. 嵌入式系統中激勵有兩類：
1）周期性激勵。在每個可預測的時間時隔內發生。舉例來說，系統可能每隔50ms檢查一次傳感器，根據傳感器的值（激勵）采取響應行動。
2）非周期性激勵。這種激勵是不規則地發生的，也是不可預測的。通常使用計算機的中斷機制發送信號，中斷指示輸入/輸出傳輸完成且數據已經在緩沖器中了。
52. 實時軟件設計過程可能包含以下幾步：
（1）平台選擇。為系統選擇一個執行平台，即要使用的硬件和實時操作系統。影響選擇的因素包括系統的時序限制、可用電源的限制、開發團隊的經驗、交付系統的價格目標。
（2）激勵/響應識別。包括識別系統必須處理的激勵和對每種激勵相應的一個或多個響應。
（3）時序分析。對於每種激勵和相應的響應，找到應用於激勵和響應處理的時序約束，用於在系統中為進程建立時限。
（4）進程設計。將激勵和響應處理聚集到幾個並發的進程中，然后優化進程體系結構，以反映出需要實現的特殊需求
（5）算法設計。對於每個激勵和響應設計算法執行所需要的運算。算法設計需要在設計過程中相對早些進行，給出要求處理的數量的提示和完成處理所需要的時間的提示。這對於計算密集型任務（如信號處理）是相當重要的。
（6）數據設計。定義進程交換的信息以及協調信息交換的事件，並且設計相應的數據結構管理信息交換。幾個並發進程可以共享這些數據結構。
（7）進程調度。設計調度系統確保進程及時開始，以滿足它們的時限要求。
52. 3種經常使用的實時的體系結構模式如下。
（1）觀察和反應。該模式用於當一組傳感器周期性地監控和顯示的時候。當傳感器顯示已經發生了某個事件時（如電話來電），作為反應系統會啟動一個進程來處理此事件。
（2）環境控制。該模式用於某些系統，這些系統包括能提供環境信息的傳感器和改變環境的執行器。根據傳感器檢測到的環境改變，控制信號被發送到系統的執行器。
（3）處理管道。該模式用於在數據被處理之前需要從一種表示變換到另一種表示的時候。變換實現為一系列可並行執行的處理步驟。由於單獨的核或處理器可以執行每個變換，因此該模式允許非常快速的數據處理。
53．汽車剎車系統控制器中，設計的起始點是針對系統中的每種執行器類型給出一個模式實例。這里有4個執行器，每一個控制一個車輪上的制動。把單個傳感器進程結合到一個監控所有車輪的車輪監控進程，該監控進程監視各個車輪上的傳感器。傳感器進程監控每個車輪狀態，判斷車輪是轉動還是抱死。一個單獨的進程監視駕駛員踩剎車踏板的壓力。其防滑制動系統的控制系統體系結構。
54．當分析嵌入式實時系統的時序需求和設計系統滿足這些需求的時候，要考慮3個主要因素：時限，頻率，執行時間
55. 實時操作系統為實時系統管理進程和資源的分配。它啟動和停止進程，使得能夠處理激勵並分配存儲器和處理器資源給進程。實時操作系統的組件關系圖。
56. 請描繪設計分布式系統中的中間件的組件關系圖。
57. 兩種不同類型的客戶-服務器結構模型：
（1）瘦客戶機模型。其表示層在客戶機端實現，其他層（數據管理、應用處理和數據庫）在服務器上實現。客戶機軟件可能是專門在客戶機上編寫的程序以處理表示。不過，更常見的情況是在客戶機上使用Web瀏覽器來表示數據。
（2）胖客戶機模型。一部分或者所有的應用處理都在客戶機上執行。數據管理和數據庫功能在服務器上實現。
58. 面向Web服務的體系結構的主要標准有：SOAP，WSDL，WS-BPDL
\59. 務接口設計有3個階段：
（1）邏輯接口設計，找出與服務關聯的操作、這些操作的輸入和輸出，以及與這些操作關聯的異常。
（2）消息設計，設計由服務發送和接收的消息結構。
（3）WSDL開發，用WSDL語言將邏輯設計和消息設計翻譯成抽象接口描述。
\60. 軟件體系結構的評估方法主要有兩種，即SAAM和ATAM。（軟件架構分析，體系結構權衡分析）
61. 評估體系結構的整體復雜性，一種很有用的技術是考慮體系結構中構件間的依賴關系，這些依賴關系是由系統中的信息流或控制流驅動的。
三種類型的依賴是：1.共享依賴 2.流依賴 3.約束依賴