第一篇：軟件體系結構解讀
創(chuàng)建型模式
1、工廠方法模式
工廠方法模式包含如下角色： i.Product：抽象產(chǎn)品 ii.ConcreteProduct：具體產(chǎn)品 iii.Factory：抽象工廠 iv.ConcreteFactory：具體工廠 結構圖：
ProductFactory+factoryMethod(): Product...ConcreteProduct<
2、抽象工廠模式
抽象工廠模式包含如下角色： i.AbstractFactory：抽象工廠 ii.ConcreteFactory：具體工廠 iii.AbstractProduct：抽象產(chǎn)品 iv.Product：具體產(chǎn)品 結構圖：
時序圖：
3、單例模式
單例模式包含如下角色： i.Singleton：單例 結構圖：
Singleton-instance: Singleton-Singleton()+getInstance(): Singleton...if(instance==null)instance=new Singleton();return instance;instance 時序圖：
結構型模式
4、組合模式
組合模式包含如下角色： i.Component: 抽象構件 ii.Leaf: 葉子構件 iii.Composite: 容器構件 iv.Client: 客戶類
結構圖：
ComponentClient++++operation()add(Component c)remove(Component c)getChild(int i)...Leaf+operation()...for(Component child:children){ child.operation();}++++Compositeoperation()add(Component c)remove(Component c)getChild(int i)...children 時序圖：
5、外觀模式 外觀模式包含如下角色： i.Facade: 外觀角色 ii.SubSystem:子系統(tǒng)角色 結構圖：
ClientFacadeSubSystemASubSystemBSubSystemC
時序圖：
6、適配器模式
適配器模式包含如下角色： i.Target：目標抽象類 ii.Adapter：適配器類 iii.Adaptee：適配者類 iv.Client：客戶類
結構圖：類適配器
ClientTarget+request()...Adaptee+specificRequest()...Adapter+request()...specificRequest();對象適配器： ClientTarget+request()...Adaptee+specificRequest()...Adapter+request()...adapteeadaptee.specificRequest();時序圖：
7、代理模式
代理模式包含如下角色： i.Subject: 抽象主題角色 ii.Proxy: 代理主題角色 iii.RealSubject: 真實主題角色
結構圖：
Subject+request()...ClientProxy-realSubject: RealSubject+preRequest()+request()+postRequest()...preRequest();realSubject.request();postRequest();RealSubjectrealSubject+request()...時序圖：
行為型模式
8、迭代器模式
迭代器模式包含如下角色： i.Iterator: 抽象迭代器 ii.ConcreteIterator: 具體迭代器 iii.Aggregate: 抽象聚合類 iv.ConcreteAggregate: 具體聚合類 結構圖：
IteratorAggregate+createIterator()++++first()next()hasNext()currentItem()ConcreteIteratorConcreteAggregate+createIterator()...++++first()next()hasNext()currentItem()時序圖：
9、觀察者模式
觀察者模式包含如下角色： i.Subject: 目標 ii.ConcreteSubject: 具體目標 iii.Observer: 觀察者 iv.ConcreteObserver: 具體觀察者 結構圖：
時序圖：
10、命令模式 命令模式包含如下角色： i.Command: 抽象命令類 ii.ConcreteCommand: 具體命令類 iii.Invoker: 調(diào)用者 iv.Receiver: 接收者 v.Client:客戶類
結構圖：
InvokerCommand+execute()...ClientReceiver+action()...ConcreteCommandreceiver-state: +execute()...receiver.action();時序圖：
11、策略模式
策略模式包含如下角色： i.Context: 環(huán)境類 ii.Strategy: 抽象策略類 iii.ConcreteStrategy: 具體策略類
結構圖：
Context-strategy: Strategy+algorithm().........strategy.algorithm();......strategyStrategy{abstract} +algorithm()...ConcreteStrategyA+algorithm()...ConcreteStrategyB+algorithm()...時序圖：
讀書的好處
1、行萬里路，讀萬卷書。
2、書山有路勤為徑，學海無涯苦作舟。
3、讀書破萬卷，下筆如有神。
4、我所學到的任何有價值的知識都是由自學中得來的?！_爾文
5、少壯不努力，老大徒悲傷。
6、黑發(fā)不知勤學早，白首方悔讀書遲。——顏真卿
7、寶劍鋒從磨礪出，梅花香自苦寒來。
8、讀書要三到：心到、眼到、口到
9、玉不琢、不成器，人不學、不知義。
10、一日無書，百事荒廢。——陳壽
11、書是人類進步的階梯。
12、一日不讀口生，一日不寫手生。
13、我撲在書上，就像饑餓的人撲在面包上?！郀柣?/p>
14、書到用時方恨少、事非經(jīng)過不知難?！懹?/p>
15、讀一本好書，就如同和一個高尚的人在交談——歌德
16、讀一切好書，就是和許多高尚的人談話?！芽▋?/p>
17、學習永遠不晚。——高爾基
18、少而好學，如日出之陽；壯而好學，如日中之光；志而好學，如炳燭之光?！獎⑾?/p>
19、學而不思則惘，思而不學則殆?！鬃?/p>
20、讀書給人以快樂、給人以光彩、給人以才干?！喔?/p>
第二篇：軟件體系結構期末考試
軟件體系結構期末考試
一、題目（論述題）：
結合參與開發(fā)的軟件工程項目，①論述采用的軟件體系結構風格或應用框架，②論述采 用的軟件設計基本原則和策略。
二、題目要求：
（1）簡要說明軟件體系結構的性質(zhì)、研究意義和目標是什么?
（2）簡要說明軟件設計風格、軟件應用框架和軟件設計模式的特征和區(qū)別？
（3）簡要說明系統(tǒng)中采用的中間件的作用和目標，（如果沒有，請選擇一種與系統(tǒng)契合的中間件進行描述）。
（4）假設系統(tǒng)沒有采用SOA的架構，請簡述SOA軟件體系結構的基本概念，Web Service的主要協(xié)議。
三、內(nèi)容要求
作業(yè)格式要求：
1、給出的標題。
2、報告內(nèi)容組織結構清晰，語句流暢，無錯別字。
3、圖、表描述恰當、與內(nèi)容契合、清晰。圖、表序號標注準確。
4、A4紙，宋體小4號字，標準頁邊距，行間距固定值18磅，頁碼右下。
交打印稿。不多于20頁，可正反面打印。
四、評分細則
1、題目整體結構、語言表達、整體格式（20分）
2、軟件體系結構的性質(zhì)、研究意義和目標(5分)
3、軟件設計風格、軟件應用框架和軟件設計模式的特征和區(qū)別（5分）
4、系統(tǒng)中間件表述（5分）
5、SOA、WebService簡述（5分）
6、論述部分，既要描述，也要有論證（包括適當?shù)脑u估）（60分）
五、總評成績
期末成績*70%+平時成績
第三篇：軟件體系結構實驗指導書
《軟件體系結構》實驗指導書
實驗一
系統(tǒng)的用例模型
實驗名稱：系統(tǒng)的用例模型
實驗類型: 設計性實驗 學
時：2課時
一、實驗目的
1．熟悉用例圖的基本功能和使用方法。
2．鍛煉結合給定題目，進行有效需求分析的能力。3．掌握如何使用建模工具繪制用例圖的方法。
二、實驗器材
1．計算機一臺。
2．UML建模工具，比如軟件ArgoUML，Rational Rose 或StarUML。
三、實驗內(nèi)容
在理解用例圖的基本功能和使用方法的基礎上，結合具體問題，完成對系統(tǒng)的需求建模，得到用例模型后，應針對每個用例進行業(yè)務分析，說明其具體的業(yè)務流程。用Rational Rose或StarUML工具軟件繪制系統(tǒng)的用例圖。下文以Rational Rose為例講解基本步驟。
四、實驗步驟
1．結合實際給定題目，完成系統(tǒng)的需求建模。
2．針對每個用例進行業(yè)務分析。以圖書管理系統(tǒng)中“刪除讀者信息”用例為例來說明實驗具體步驟。
（1）分析：在圖書管理系統(tǒng)中,管理員首先登錄系統(tǒng),系統(tǒng)驗證通過后,管理方可向系統(tǒng)查詢數(shù)據(jù),在查詢后,系統(tǒng)會給出提示,有沒有找到相關的數(shù)據(jù),管理員根據(jù)系統(tǒng)查詢的返回結果,進行下一步的操作,就是刪除讀者,在刪除的過程中,系統(tǒng)會對查詢得到的結果判斷該記錄是否可以刪除,若可以刪除,則給刪除提示,若不能刪除,也給相關的提示信息。
（2）根據(jù)分析結果，書寫業(yè)務流程，一般包含以下信息：
①管理員在錄入界面，輸入待刪除的讀者名；
②“業(yè)務邏輯”組件在數(shù)據(jù)庫中，查找待刪除的讀者名； ③如果不存在，則顯示出錯信息，返回步驟①，如果存在則繼續(xù)； ④“業(yè)務邏輯”組件判斷“待刪除的讀者”是否可以刪除； ⑤如果不可以，則顯示出錯信息，返回步驟⑧，如果可以則繼續(xù)； ⑥在數(shù)據(jù)庫中，刪除相關信息； ⑦顯示刪除成功信息； ⑧結束。
3．根據(jù)分析結果，繪制用例圖。以圖書管理系統(tǒng)中“刪除讀者信息”用例為例說明具體繪圖步驟:(1)在用例圖上雙擊main,出現(xiàn)如圖1.1所示,為繪制用例圖做好準備。
圖1.1(2)在圖中的工具欄選取Actor圖標，在右邊的圖中添加一個Actor，并輸入名稱:administrator,如圖1.2所示。
(3)在左邊的工具欄中，選取用例的圖標，在右邊的圖中畫出一個用例，并輸入用例的名稱：login。
圖1.2（4）按照步驟（3），繪制出如圖1.4和圖1.5的兩個用例。
圖1.3
圖1.4
圖1.5（5）在繪出了用例后，接下來的是繪制參與者與用例實現(xiàn)，如圖1.6所示。
圖1.6
（6）根據(jù)步驟（5），同時完成如圖1.7和圖1.8。此時，刪除讀者用例圖就到此完成。其系統(tǒng)查詢讀者信息等其他的功能會在時序圖和活動圖中描繪。
（7）根據(jù)分析情況，進一步添加或細化用例圖。
圖1.7
圖1.8
五、實驗報告要求
1． 說明系統(tǒng)的需求建模結果，對主要用例整理用例圖。2． 小結實驗心得體會。
實驗二 系統(tǒng)的類模型
實驗名稱：系統(tǒng)的類模型
實驗類型: 設計性實驗 學
時：2課時
一、實驗目的
1．理解類的基本概念。
2．掌握如何從需求分析中抽象出類的方法。
3．掌握在ArgoUML，Rational Rose或StarUML中繪制類的操作方法。
二、實驗器材
1．計算機一臺。
2．ArgoUML，Rational Rose 或StarUML工具軟件。
三、實驗內(nèi)容
完成實驗一后，對給定題目的系統(tǒng)的需求的初步分析，得出系統(tǒng)的用例圖，通過對用例的業(yè)務流程的分析，我們可以初步了解系統(tǒng)的業(yè)務處理流程。本實驗需要對系統(tǒng)進行靜態(tài)建模，這就需要從系統(tǒng)的用例圖去尋找和發(fā)現(xiàn)類。用Rational Rose或StarUML工具軟件繪制系統(tǒng)的類圖。下文以Rational Rose為例講解基本步驟。
四、實驗步驟
1．分析：由前面試驗對需求的分析抽象出類。2．繪制類圖的步驟：
（1）打開前面初步構建的UML模型文件;（2）打開Rose中的邏輯視圖（Logical View），選擇分析模型（analysis model）目錄。并在其下創(chuàng)建一個子目錄并命名為：“圖書館業(yè)務功能”。
（3）用鼠標右擊“圖書館業(yè)務功能”在彈出來的菜單中選擇“New→Class diagram”項，創(chuàng)建類圖，如圖2.1所示。
（4）雙擊新建的類圖，并點右邊控件集中選中的類的圖標，并用鼠標在圖中分別拖出一個類圖，并命名為Book，如圖2.2所示。
圖2.1
圖2.2（5）接下來的一步為設置類的屬性，在新的類中雙擊該類，在打開屬性面板中，可以看到在此可以設置類的屬性和方法等其他的信息，圖2.3所示；后撞擊Attributes這個欄目，此欄目為設置類的屬性的選項，在圖中間的單擊右鍵，可以看到有一個“Insert”的選項，選中這個選項，圖2.4所示，后在出現(xiàn)的對話框中輸入相關信息如圖2.5所示；如書本的ISBN號，在Type這個方框內(nèi)輸入此屬性的類型值，同時可以看到一欄可以設置此屬性的訪問權限，一般這些屬性都設置Private這個權限，如圖2.6所示。這個類的其他屬性也可以按照以上的做法設置，最后得到的結果是圖2.7所示。
圖2.3 圖2.4
圖2.5 圖2.6（6）設置好類的屬性，現(xiàn)在來設置類的方法（也是操作），雙擊類后在彈出的菜單上選operations這個選項，可以看到圖2.8所示，在圖中的空白地方，單擊右鍵，在彈出的菜單中選insert這個選項，也就只有這個選項可用，見圖2.9，接著輸入方法名，同時可以設置該方法的返回類型，也可以在Documentations的方框內(nèi)填寫一些相關的方法說明，如圖2.12所示，設置好該方法的訪問權限，見圖2.13。類的其他方法也可以按上面來設置好，最后，得到該類的其他方法見類2.14。
圖2.7 圖2.8
圖2.9
圖2.11
圖2.10
圖2.12
圖2.13 圖2.14（7）至此，類的方法和屬性都設置好了，如圖2.15所示。
圖2.15（8）按照上面的步驟設置好所有類的屬性和方法。
（9）為各個類添加關系，由關聯(lián)、泛化、依賴等關系來靜態(tài)描述業(yè)務。
五、實驗報告要求
1．整理實驗結果。2．小結實驗心得體會。實驗三 系統(tǒng)的狀態(tài)建模
實驗名稱：系統(tǒng)的狀態(tài)建模
實驗類型: 設計性實驗 學
時：2課時
一、實驗目的
1．熟悉狀態(tài)圖的基本功能和使用方法。2．掌握如何使用建模工具繪制狀態(tài)圖方法。
二、實驗器材
1．計算機一臺。
2．ArgoUML，Rational Rose或StarUML 工具軟件。
三、實驗內(nèi)容
完成實驗一后，對給定題目的系統(tǒng)的需求的初步分析，得出系統(tǒng)的用例圖，通過對用例的業(yè)務流程的分析，我們可以初步了解系統(tǒng)的業(yè)務處理流程，但對業(yè)務處理過程的處理狀態(tài)間轉換了解仍不夠，這不利于設計人員對系統(tǒng)業(yè)務的進一步理解，而狀態(tài)圖能從對象的動態(tài)行為的角度去描述系統(tǒng)的業(yè)務活動。因此，在本實驗主要完成用例的狀態(tài)圖。
四、實驗步驟
1．業(yè)務分析：由前面實驗對用例的描述和分析得到業(yè)務動態(tài)行為的狀態(tài)分析。以用例“還書”為例，還書業(yè)務的動態(tài)行為是由：空閑（idle）、圖書查找（finding）、還書（reversion）、失敗（Failure）、歸還成功（Success）5種狀態(tài)及激活相互轉換的事件。
2．繪制狀態(tài)圖。
還書的狀態(tài)圖，還書的主要業(yè)務都是由管理員來完成，首先管理員必須先登錄系統(tǒng)，并通過驗證后，便可以進行下一步的操作，查找該書的相關信息，如存在，則進行還書操作，如不存在該信息，則給出提示信息；
繪圖步驟：
（1）在用例圖中的還書（revesion）用例，單擊右鍵，如圖3.1所示，新建一個狀態(tài)圖，命名為revesion狀態(tài)圖，圖3.2所示。
圖3.1
圖3.2（2）雙擊“receivesion”狀態(tài)圖，展開后，在左邊的工具欄上選取一個實心圓點，此結點為開始結點，圖3.3所示；當還書的時候，操作者先要詢問系統(tǒng)的狀態(tài)，如果系統(tǒng)忙，操作者則必需等待，因此，得到系統(tǒng)的兩種狀態(tài)，如圖3.5所示。
圖3.3
圖3.4
圖3.5（3）操作者在詢問系統(tǒng)和狀態(tài)后，得到的圖3.6所示兩種狀態(tài)，如果系統(tǒng)忙，操作者必需要等待、結束，如圖3.7和圖3.8所示，重返步驟（1）。
圖3.6
圖3.7
圖3.8（4）如系統(tǒng)空閑，則進行對還書的信息進行查詢操作，圖3.9所示；查詢也有兩種結果，一是查詢得到該書的相關信息，二查詢不到該書的相關信息；則此時有兩種狀態(tài)，需要建立兩種狀態(tài)，如圖3.10所示。
圖3.9
圖3.10（5）最后，操作者進行了操作后，系統(tǒng)會給出操作的結果給操作者；操作成功或失敗，都會有提示信息給出。整個的還書的過程便完成；圖3.11所示。
（7）根據(jù)分析設計情況，進一步添加或細化狀態(tài)圖。
圖3.11
五、實驗報告要求
1．整理實驗結果。2．小結實驗心得體會。
第四篇：軟件體系結構實驗一
南京信息工程大學實驗（實習）報告實驗（實習）名稱（實習）日期系專業(yè)年級班次姓名
一、實驗目的1）了解智能模型的概念
2）查閱有關SVM算法，并作理解
二、實驗要求
1）簡介 智能模型基于知識的軟件開發(fā)模型，它與專家系統(tǒng)結合在一起。該模型應用基于規(guī)則的系統(tǒng)，采用歸納和推理機制，幫助軟件人員完成開發(fā)工作，并使維護在系統(tǒng)規(guī)格說明一級進行。該模型在實施過程中要建立知識庫，將模型本身、軟件工程知識與特定領域的知識分別存入數(shù)據(jù)庫。以軟件工程知識為基礎的生成規(guī)則構成的專家系統(tǒng)與含應用領域知識規(guī)則的其他專家系統(tǒng)相結合，構成這一應用領域軟件的開發(fā)系統(tǒng)。
2）詳細說明 智能模型也稱為“基于知識的軟件開發(fā)模型”，它把瀑布模型和專家系統(tǒng)結合在一起，利用專家系統(tǒng)來幫助軟件開發(fā)人員的工作。該模型應用基于規(guī)則的系統(tǒng)，采用歸納和推理機制，使維護在系統(tǒng)規(guī)格說明一級進行。這種模型在實施過程中以軟件工程知識為基礎的生成規(guī)則構成的知識系統(tǒng)與包含應用領域知識規(guī)則的專家系統(tǒng)相結合，構成這一應用領域軟件的開發(fā)系統(tǒng)。
智能模型擁有一組工具（如數(shù)據(jù)查詢、報表生成、數(shù)據(jù)處理、屏幕定義、代碼生成、高層圖形功能及電子表格等），每個工具都能使開發(fā)人員在高層次上定義軟件的某些特性，并把開發(fā)人員定義的這些軟件自動地生成為源代碼。這種方法需要四代語言（4GL）的支持。4GL不同于三代語言，其主要特征是用戶界面極端友好，即使沒有受過訓練的非專業(yè)程序員，也能用它編寫程序；它是一種聲明式、交互式和非過程性編程語言。4GL還具有高效的程序代碼、智能缺省假設、完備的數(shù)據(jù)庫和應用程序生成器。目前市場上流行的4GL（如Foxpro等）都不同程度地具有上述特征。但4GL目前主要限于事務信息系統(tǒng)的中、小型應用程序的開發(fā)。
3）必要性
智能模型所要解決的問題是特定領域的復雜問題，涉及大量的專業(yè)知識，而開發(fā)人員一般不是該領域的專家，他們對特定領域的熟悉需要一個過程，所以軟件需求在初始階段很難定義得很完整。因此，采用原型實現(xiàn)模型需要通過多次迭代來精化軟件需求。
智能模型以知識作為處理對象，這些知識既有理論知識，也有特定領域的經(jīng)驗。在開發(fā)過程中需要將這些知識從書本中和特定領域的知識庫中抽取出來（即知識獲?。?，選擇適當?shù)姆椒ㄟM行編碼（即知識表示）建立知識庫。將模型、軟件工程知識與特定領域的知識分別存入數(shù)據(jù)庫，在這個過程中需要系統(tǒng)開發(fā)人員與領域專家的密切合作。
智能模型開發(fā)的軟件系統(tǒng)強調(diào)數(shù)據(jù)的含義，并試圖使用現(xiàn)實世界的語言表達數(shù)據(jù)的含義。該模型可以勘探現(xiàn)有的數(shù)據(jù)，從中發(fā)現(xiàn)新的事實方法指導用戶以專家的水平解決復雜的問題。它以瀑布模型為基本框架，在不同開發(fā)階段引入了原型實現(xiàn)方法和面向對象技術以克服瀑布模型的缺點，適應于特定領域軟件和專家決策系統(tǒng)的開發(fā)。
三、實驗結果
通過本次實驗，我對智能模型有了一定的了解和認識，同時也查閱了有關SVM算法的有關知識，并作了一定的理解，對該算法有了一定的認識。
第五篇：2.1-2.2軟件件體系結構作業(yè)答案
2.1 工廠方法與抽象工廠模式
一、在簡單工廠方法模式、工廠方法模式與抽象工廠模式中，哪個模式符合開閉原則？為什么？哪個模式一般不符合開閉原則？或者說明在哪種情況下，開閉原則成立，哪種情況下，開閉原則不成立。
答：
簡單工廠模式一般不符合開閉原則。在簡單工廠模式中，如果要增加一個新產(chǎn)品類，相應地在工廠類中也要增加一個條件語句，用于創(chuàng)建新的產(chǎn)品類的對象。也就是說，必須修改工廠類的源代碼。
工廠方法模式和抽象工廠模式符合開閉原則。因為在工廠方法模式和抽象工廠模式中，無需修改或者重新編譯已經(jīng)存在的代碼，就可以添加新的產(chǎn)品類。
開閉模式是指對擴展開放，對修改關閉，說的更通俗點，就是說開發(fā)了一個軟件，應該可以對它進行功能擴展（開放），而在進行這些擴展的時候，不需要對原來的程序進行修改（關閉）。
二、圖2.17所示設計類圖是關于游戲軟件的設計。
在該設計中，SlowGameFactory類負責創(chuàng)建SlowFighter對象與SlowMonster對象，并且將創(chuàng)建完的對象以其超類類型返回給ClientGUI對象。然后，ClientGUI對象將操縱SlowFighter對象與SlowMonster對象，使得它們互相打斗。
問題與任務：
1、上述設計使用了什么設計模式？
2、請在以上設計類圖中添加4個新的類MedFighter、SuperFighter、MedMonster和SuperMonster，以便使得MedFighter對象能夠對應于MedMonster對象；SuperFighter對象能夠對應于SuperMonster對象，繪制新設計類圖；
3、除了以上添加的4個類以外，在以上類圖中還應該添加什么類？
4、描述新的設計類圖；
5、明確說明新設計的優(yōu)點。
答：
1、上述設計使用抽象工廠設計模式。
23、SuperGameFactory
MedGameFactory
4、多個抽象產(chǎn)品類，每個抽象產(chǎn)品類可以派生出多個具體產(chǎn)品類。
一個抽象工廠類，可以派生出多個具體工廠類。
每個具體工廠類可以創(chuàng)建多個具體產(chǎn)品類的實例，也就是創(chuàng)建的是一個產(chǎn)品線下的多個產(chǎn)品。
5、工廠方法模式只有一個抽象產(chǎn)品類，而抽象工廠模式有多個。
工廠方法模式的具體工廠類只能創(chuàng)建一個具體產(chǎn)品類的實例，而抽象工廠模式可以創(chuàng)建多個。
2.2 生成器模式
一、在例2.5的設計中，添加一個經(jīng)濟型房屋生成器類，命名為EconHouseBuilder。請繪制新設計的類圖。
點擊咨詢 