1、什麼是軟件體系結構？
軟件體系結構 = 構件+連接件+約束。關於對構件的理解參見討論題二。
連接件是一類特殊的構件，是將構件連接在一起的軟件構造體。而約束是指按照什麼標準或要求將構件連接起來。三者的關係可以表述爲：按照系統的性能約束或者功能約束，用連接件將構件組裝成軟件系統。
學習重點：理解構件。完成大作業的核心工作：尋找和確定擬開發系統的構件。
從領域需求到系統功能、再到系統結構，經歷了兩次轉化。在開發過程中，就要將需求集合轉化爲功能集合，再轉化爲系統的構件集合，然後實施系統開發。
軟件體系結構的作用猶如建築工程中的“施工圖紙”，或者稱之爲“藍圖”。沒有圖紙，不能開工。同樣地，沒有軟件體系結構，就無法構造複雜的軟件系統。由此可見，軟件體系結構的重要性。
2、如何理解構件？
軟件體系結構三要素之一的構件，按照書中的定義，構件是可預製、可重用的軟件構造體，可以是模塊、子系統甚至系統，猶如建築中的預製板、預製粱、隔離牆等預先在工廠中做好的、可以用在一些建築中的構造體。可預製，就是事先做好的；可重用，就是可以在不同的系統中使用。例如登錄/註冊模塊可以在很多軟件系統中使用，電子商務中的客戶、商品和訂單模塊就是該領域軟件體系結構中的構件。同樣地，在每一個應用領域中使用的軟件系統，都存在若干構件。
所以，理解構件就要記住它的兩大特徵：事先做好的，可以重複使用的。軟件開發歷經幾十年的實踐，已經到了採用“搭積木”的方式構造軟件系統的階段。這些或大或小的“軟件積木”(Building blocks)，其中有些就是構件。面向服務的體系結構（SOA）中的服務組件架構（Service Component Architecture, SCA）就是採用搭積木的方式構建軟件系統。
3、怎樣理解概念視圖中的“概念”？
在體系結構圖示方法中概念視圖具有基礎作用，是在對領域需求的準確理解基礎上產生的。它不是對將要開發系統的具體模塊的命名，而是將需求集合轉化爲功能集合的一種抽象表示。如果說頂級用例圖界定了軟件系統的主要功能，概念視圖具有同樣的作用。
在課程學習和後面的大作業中，概念視圖都是重點，也是難點。後面在講到用例驅動的體系結構設計時，還會談及如何將用例圖轉化成概念視圖的問題。
要得到概念視圖中的概念，即構件和連接件的命名，務必對領域需求有完整準確的把握，然後將需求適當歸併，對應到一個功能集合，由此可以抽象出準確的概念構件來（包含連接件，因爲連接件是一類特殊的構件）。
如果概念視圖不準確，後面的模塊視圖、執行視圖和代碼視圖就都會出問題。可見，體系結構中的概念視圖，其重要性如同UML中的頂級用例圖。
4、如何將概念視圖轉換到模塊視圖？
概念視圖是一個體系領域活動的抽象的體現，略去了細節。由中心視鏡的例子看出模塊視圖就是對應的將概念視圖分層，將具有相同功能的模塊劃分爲同一層，建立模塊視圖，約束模塊之間的使用關係，從而對體系的功能更好的在模塊視圖中進行進一步的具體實現。最後將概念視圖中的關係轉化爲模塊視圖中各個層之間的關係。
5、模型是什麼？爲什麼說PIM至關重要？
模型有多種，如數學模型、物理模型、建築模型等等。模型具有基礎性、可參照、可重用的特點。模型是對某個事物高度抽象的結果。在軟件開發中，對領域活動深入分析後，利用面向對象方法可以建立該領域的軟件模型，隨後在具體的系統開發中就可以利用此模型。特別是非常複雜的軟件系統開發，獲取領域模型是第一步。然後可以擴展思考，看能否將該模型跨領域應用，產生更高層次的模型。
所謂PIM，是指與開發平臺無關的模型，這樣的模型因爲與具體的軟件開發技術無關，因此具有很高的可重用性，以及可擴展性，即由該模型向各種具體的PSM轉換，甚至向其它領域的PIM轉換。當然，在具體的軟件開發實踐中，也有“逆流而上”的，即從具體的PSM向上抽象，或者叫泛化，得到PIM。
6、領域驅動的含義是什麼？其中的產品線結構有什麼特點？
領域驅動的體系結構設計具有鮮明的領域特徵，例如系統軟件中的Windows操作系統，從早期的Win95、Win 98、Win2000，到後面的WindowsXP、win7、Win10，已經演變爲網絡操作系統，而且有企業版、家庭版等適應不同需求的類型，但是操作系統的核心架構和對應的核心功能沒有變，只是隨着外部需求的變化逐漸增加一些構件，如用戶界面的圖形化構件、網絡安全構件等。領域驅動的體系結構設計，就是要得到該領域軟件體系架構的參考模型，該模型具有可參照、可擴展、可重用的特點，便於在該領域中開發軟件系統，而且可以隨領域活動或者需求變化而變化。
產品線結構是DSSA的一種特例，是針對領域中某一類產品的軟件開發，除了具有上面提到的一些特點，它還具有一些與該類產品相關的一些專用構件。如高校教學管理軟件除了具有一般管理信息系統軟件的基礎功能外，還具有體現高校教學活動的若干構件，它們是所有高校都要使用的，具有一定的應用範圍。
通俗的回答：
領域驅動的含義：
1.領域：就是用戶應用軟件的主題區域。比如“機票預訂”，“確認收支”等。
2.驅動：就是試圖讓我們的思路更順暢，場景的切換更平滑。
3.那麼領域驅動結合在一起，被稱爲領域驅動設計，簡稱: DDD，DDD是一-種以領域爲核心的設計和開發理念。
4.DDD就是用來應對領域的複雜性，主要爲了應對軟件的複雜性。
產品線結構特點：
1.要了解產品線結構的特點，首先先了解一下產品線結構是什麼：可以說它就是在一個公共的軟件資集合上建立來的，共享同一個特性集合的系統集合。
2.軟件產品線的開發有4個技術特點:過程驅動、特定領域、技術支持和架構爲中心。
7、如何將用例圖轉化成概念視圖？
用例圖是用來描述領域活動的，顯示出一些角色、一些活動以及角色和活動之間的聯繫。頂級用例圖界定了將要開發的軟件系統的功能邊界，甚至從中可以確定主要的子系統、主要的實體類，它們是領域業務邏輯和業務流程的抽象描述和可視化表達。因此，在準確的頂級用例圖基礎上，可以尋求得到體系結構的概念視圖。首先，看哪些活動是基礎的、核心的，它們對應的軟件構造塊必將是要重用的（需要持久保存的實體類，登陸/註冊模塊，用戶界面設計模塊，核心功能模塊等）；然後，考察它們是否可以預製，即事先做好的，然後可以應用到該領域的很多軟件系統中，滿足這兩點的軟件模塊就是構件；接着，從用例圖的聯繫中抽取連接件，聯繫可以是角色和活動的聯繫，也可以是活動之間的聯繫，要認真推敲，因爲連接件是一類特殊的構件，也要滿足可預製、可重用的要求；最後按照概念視圖的規範表示畫出。
通俗的說：
首先用例圖是指由參與者（Actor）、用例（Use Case），邊界以及它們之間的關係構成的用於描述系統功能的視圖，它是系統的藍圖。用例圖呈現了一些參與者，一些用例，以及它們之間的關係，主要用於對系統、子系統或類的功能行爲進行建模。而概念視圖主要是整個系統的抽象結構表述，我們需要通過用例圖進行分析，找出功能模塊，並通過用例圖找出用例與用例、用例與活動之間的聯繫，最後根據功能模塊把找到的功能和聯繫進行整合，依靠概念視圖的畫法將其畫出。
8、三種體系結構設計方法之間有怎樣的聯繫？
模型驅動、領域驅動和用例驅動，三種設計方法均來自對領域活動業務邏輯和業務流程的準確把握，只是解決問題的路徑和側重點不同。用例驅動從用例入手，用例來自領域活動的主要場景，開發者要關注場景中的人、物和事，直觀、可操作性強；模型驅動抽象程度較高，針對複雜的領域問題，不會直接就能夠得到模型，可能需要將其拆分成若干個子問題，然後分別求解，再將子模型組合成一個總體模型；至於領域驅動，則從領域或其中更窄的產品線入手，應用範圍明確，針對性強，領域特徵明顯。用例驅動和領域驅動的最終結果都要得到模型，相關領域軟件系統的開發最終都會轉化爲模型驅動。
三種設計方法運用軟件技術可以優化領域的業務流程，提高工作效率和質量。需要注意的是，某些模型是跨領域的，即帶有普遍性，如數據是分散的，但是監控是集中的一類應用（如醫院的中央病房監控系統、城市交通管理系統、港口調度指揮系統等等）。還有Rosa的早餐預訂系統，經過泛化後可以用於一類應用—標準化需求與多樣化需求的協調和平衡。所以，模型驅動的設計方法是本課程學習的核心和重點，特別是掌握某些具有普遍應用意義的模型對軟件開發有益。
9、如何選擇恰當的設計模式或風格？
具體問題具體分析，對症下藥才能藥到病除。
很多領域的軟件開發可以採用MVC模式，即常見的三層架構：應用層（或稱之爲視圖層View），模型層（Model，業務邏輯層）和數據庫層（擴展爲基礎設施層）。至於Controler 是控制各層之間的信息傳遞（命令信息和數據信息）。操作系統一般採用事件驅動的設計風格；不需要太多交互的應用如數據處理可採用管道-過濾器模式；而對資源佔用有較多要求和條件的應用，倉庫-黑板是一個不錯的選項，因爲其存儲空間有限或者佔用時間有限；還有一些層次結構明顯、各層功能清晰的領域如行政管理、地域管理等，可採用分層風格的體系結構設計。當然，針對複雜的軟件工程應用如智慧城市，要採用若干設計模式的組合，甚至研發出新的設計模式。
10、如何理解“按需服務，隨需應變”的SOA理念？
用戶需求是不斷變化的，套用哲學語言就是“變化是永遠不變的”。軟件系統如何適應需求的變化？重新開發？不可行！修修補補，未必行。借鑑機械系統中零件的可裝配、可互換，軟件開發也希望實現可擴展、可重用、可維護。SOA就是這樣演化而來，使系統開發朝着構件化、集成化發展。每個構件具有標準化的構成和外部接口，構件之間的聯繫可以隨需求變化，即整個系統可以根據用戶需求靈活組合，可裝卸，可替換，或者說是通用構件+專用構件，前者構成服務總線或平臺，後者掛接在上面實現專用功能。這種“按需服務，隨需應變”的軟件系統開發方式會使多方受益。不恰當地比喻，有點像“變形金剛”，根據需要可以“變成”想要的東西，但是構成它的基本零件集合沒變。
11、用SCA如何構造SOA中的“A”？
按照SOA“按需服務，隨需應變”的理念，開發者在實踐中發展建立起SCA（服務組件架構）這一標準，即用可實現互操作的、標準化構成的組件構造軟件系統，每一個組件封裝了一個服務，大的組件是由一組小的組件構成。按照這種方式建造的軟件系統，其整體架構具有了可重組、可裝配的特點。
12、服務組合的具體規範是怎樣實現的？
XML（可擴展標記語言）是一種可自定義、可描述任何事物、人與計算機均可讀的語言，功能強大，應用範圍廣泛。
在SCA中用於表示組件（Component）和由組件構成的服務組合（Composite）。每一個服務組合由接口（Interface）、引用（Reference）、服務（Service）、包含（Inclusion）構成，均採用XM表示。一個系統由一系列組合構成。
13、爲什麼說SDO是一個通用的數據訪問規範？
SDO（Service Data Object）是SOA中的另一個標準，也是SCA中一個特殊的組件，提供了一套與數據源無關的API。
利用SDO可以訪問RDB、XMLDB、OODB等各種形式的數據庫，保留數據訪問和操作的歷史記錄。
14、軟件體系結構將如何發展？
萬物皆可互聯，軟件無處不在。伴隨第四次工業革命逐步展開，以機械爲核心的工業將向以軟件爲核心的工業轉型。那麼，軟件體系結構會怎樣發展呢？這裏只是談點個人看法。
1、超大型、超複雜的體系結構。如智慧城市中的軟件系統，它不可能由一個單一的巨無霸系統構成，一定是通用軟硬件基礎設施+各行各業應用系統，其中包含衆多的軟件系統，具有層次結構；
2、虛實結合。CPS（ 信息物理系統，第四次工業革命的產物）中 的虛擬現實交互系統（VRIS）是聯繫物理世界和信息世界的紐帶，它會具有什麼樣的體系結構？
3、微服務架構。目前業界正在使用的技術，是SOA的演化產物，其構件的顆粒度更小，更容易實現功能調整，特別適合人機交互較多的應用領域。大家要關注它和它今後的發展。