軟體體系結構參考文獻

㈠ 需要說明一個軟體系統的各個層次的每一個程序(模塊)設計考慮的文件是什麼

摘要：
本文是在概要設計實踐和學習中的一些心得與學習筆記，希望與大家分享，如有不妥之處歡迎指正。
關鍵字：
概要設計，結構化，OOD
正文：
在需求明確、准備開始編碼之前，要做概要設計，而詳細設計可能大部分公司沒有做，有做的也大部分是和編碼同步進行，或者在編碼之後。因此，對大部分的公司來說，概要設計文檔是唯一的設計文檔，對後面的開發、測試、實施、維護工作起到關鍵性的影響。
一、問題的提出
概要設計寫什麼？概要設計怎麼做？
如何判斷設計的模塊是完整的？
為什麼說設計階段過於重視業務流程是個誤區？
以需求分析文檔還是以概要設計文檔來評估開發工作量、指導開發計劃准確？
結構化好還是面向對象好？
以上問題的答案請在文章中找。
二、概要設計的目的
將軟體系統需求轉換為未來系統的設計；
逐步開發強壯的系統構架；
使設計適合於實施環境，為提高性能而進行設計；
結構應該被分解為模塊和庫。
三、概要設計的任務
制定規范：代碼體系、介面規約、命名規則。這是項目小組今後共同作戰的基礎，有了開發規范和程序模塊之間和項目成員彼此之間的介面規則、方式方法，大家就有了共同的工作語言、共同的工作平台，使整個軟體開發工作可以協調有序地進行。
總體結構設計：
功能（加工）－>模塊：每個功能用那些模塊實現，保證每個功能都有相應的模塊來實現；
模塊層次結構：某個角度的軟體框架視圖；
模塊間的調用關系：模塊間的介面的總體描述；
模塊間的介面：傳遞的信息及其結構；
處理方式設計：滿足功能和性能的演算法
用戶界面設計；
數據結構設計：
詳細的數據結構：表、索引、文件；
演算法相關邏輯數據結構及其操作；
上述操作的程序模塊說明（在前台？在後台？用視圖？用過程？······）
介面控製表的數據結構和使用規則
其他性能設計。
四、概要設計寫什麼
結構化軟體設計說明書結構（因篇幅有限和過時嫌疑，在此不作過多解釋）
任務：目標、環境、需求、局限；
總體設計：處理流程、總體結構與模塊、功能與模塊的關系；
介面設計：總體說明外部用戶、軟、硬體介面；內部模塊間介面（註：介面≈系統界面）
數據結構：邏輯結構、物理結構，與程序結構的關系；
模塊設計：每個模塊「做什麼」、簡要說明「怎麼做」（輸入、輸出、處理邏輯、與其它模塊的介面，與其它系統或硬體的介面），處在什麼邏輯位置、物理位置；
運行設計：運行模塊組合、控制、時間；
出錯設計：出錯信息、處錯處理；
其他設計：保密、維護；
OO軟體設計說明書結構
1 概述
系統簡述、軟體設計目標、參考資料、修訂版本記錄
這部分論述整個系統的設計目標，明確地說明哪些功能是系統決定實現而哪些時不準備實現的。同時，對於非功能性的需求例如性能、可用性等，亦需提及。需求規格說明書對於這部分的內容來說是很重要的參考，看看其中明確了的功能性以及非功能性的需求。
這部分必須說清楚設計的全貌如何，務必使讀者看後知道將實現的系統有什麼特點和功能。在隨後的文檔部分，將解釋設計是怎麼來實現這些的。
2 術語表
對本文檔中所使用的各種術語進行說明。如果一些術語在需求規格說明書中已經說明過了，此處不用再重復，可以指引讀者參考需求說明。
3 用例
此處要求系統用用例圖表述（UML），對每個用例（正常處理的情況）要有中文敘述。
4 設計概述
4.1 簡述
這部分要求突出整個設計所採用的方法（是面向對象設計還是結構化設計）、系統的體系結構（例如客戶/伺服器結構）以及使用到的相應技術和工具（例如OMT、Rose）
4.2 系統結構設計
這部分要求提供高層系統結構（頂層系統結構、各子系統結構）的描述，使用方框圖來顯示主要的組件及組件間的交互。最好是把邏輯結構同物理結構分離，對前者進行描述。別忘了說明圖中用到的俗語和符號。
4.3 系統界面
各種提供給用戶的界面以及外部系統在此處要予以說明。如果在需求規格說明書中已經對用戶界面有了敘述，此處不用再重復，可以指引讀者參考需求說明。如果系統提供了對其它系統的介面，比如說從其它軟體系統導入/導出數據，必須在此說明。
4.4 約束和假定
描述系統設計中最主要的約束，這些是由客戶強制要求並在需求說明書寫明的。說明系統是如何來適應這些約束的。
另外如果本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那麼系統可能還受到其它的約束。這種情況下，要求清楚地描述與本系統有交互的軟體類型以及這樣導致的約束。
實現的語言和平台也會對系統有約束，同樣在此予以說明。
對於因選擇具體的設計實現而導致對系統的約束，簡要地描述你的想法思路，經過怎麼樣的權衡，為什麼要採取這樣的設計等等。
5 對象模型
提供整個系統的對象模型，如果模型過大，按照可行的標准把它劃分成小塊，例如可以把客戶端和伺服器端的對象模型分開成兩個圖表述。在其中應該包含所有的系統對象。這些對象都是從理解需求後得到的。要明確哪些應該、哪些不應該被放進圖中。所有對象之間的關聯必須被確定並且必須指明聯系的基數。聚合和繼承關系必須清楚地確定下來。每個圖必須附有簡單的說明。
6 對象描述
在這個部分敘述每個對象的細節，它的屬性、它的方法。在這之前必須從邏輯上對對象進行組織。你可能需要用結構圖把對象按子系統劃分好。
為每個對象做一個條目。在系統對象模型中簡要的描述它的用途、約束（如只能有一個實例），列出它的屬性和方法。如果對象是存儲在持久的數據容器中，標明它是持久對象，否則說明它是個臨時對象（transient object）。
對每個對象的每個屬性詳細說明：名字、類型，如果屬性不是很直觀或者有約束（例如，每個對象的該屬性必須有一個唯一的值或者值域是有限正整數等）。
對每個對象的每個方法詳細說明：方法名，返回類型，返回值，參數，用途以及使用的演算法的簡要說明（如果不是特別簡單的話）。如果對變數或者返回值由什麼假定的話，Pre-conditions和Post-conditions必須在此說明。列出它或者被它調用的方法需要訪問或者修改的屬性。最後，提供可以驗證實現方法的測試案例。
7 動態模型
這部分的作用是描述系統如何響應各種事件。一般使用順序圖和狀態圖。
確定不同的場景（Scenario）是第一步，不需要確定所有可能的場景，但是必須至少要覆蓋典型的系統用例。不要自己去想當然地創造場景，通常的策略是描述那些客戶可以感受得到的場景。
7.1 場景（Scenarios）
對每個場景做一則條目，包括以下內容：
場景名：給它一個可以望文生義的名字
場景描述：簡要敘述場景是干什麼的以及發生的動作的順序。
順序圖：描述各種事件及事件發生的相對時間順序。
7.2 狀態圖
這部分的內容包括系統動態模型重要的部分的狀態圖。可能你想為每個對象畫一個狀態圖，但事實上會導致太多不期望的細節信息，只需要確定系統中一些重要的對象並為之提供狀態圖即可。
8 非功能性需求
五、概要設計怎麼做
結構化軟體設計方法：
詳細閱讀需求規格說明書，理解系統建設目標、業務現狀、現有系統、客戶需求的各功能說明；
分析數據流圖，弄清數據流加工的過程；
根據數據流圖決定數據處理問題的類型（變換型、事務型、其他型）；
通過以上分析，推導出系統的初始結構圖；
對初始結構圖進行改進完善：所有的加工都要能對應到相應模塊（模塊的完整性在於他們完成了需求中的所有加工），消除完全相似或局部相似的重復功能（智者察同），理清模塊間的層次、控制關系，減少高扇出結構，隨著深度增大扇入，平衡模塊大小。
由對數據字典的修改補充完善，導出邏輯數據結構，導出每種數據結構上的操作，這些操作應當屬於某個模塊。
確定系統包含哪些應用服務系統、客戶端、資料庫管理系統；
確定每個模塊放在哪個應用伺服器或客戶端的哪個目錄、哪個文件（庫），或是在資料庫內部建立的對象。
對每個篩選後的模塊進行列表說明。
對邏輯數據結構進行列表說明。
根據結構化軟體設計說明書結構對其他需要說明的問題進行補充說明，形成概要設計說明書。
OO軟體設計方法：
在OOA基礎上設計對象與類：在問題領域分析（業務建模和需求分析）之後，開始建立系統構架。
第一步是抽取建立領域的概念模型，在UML中表現為建立對象類圖、活動圖和交互圖。對象類就是從對象中經過「察同」找出某組對象之間的共同特徵而形成類：
對象與類的屬性：數據結構；
對象與類的服務操作：操作的實現演算法；
對象與類的各外部聯系的實現結構；
設計策略：充分利用現有的類；
方法：繼承、復用、演化；
活動圖用於定義工作流，主要說明工作流的5W（Do What、Who Do、When Do、Where Do、Why Do）等問題，交互圖把人員和業務聯系在一起是為了理解交互過程，發現業務工作流中相互交互的各種角色。
第二步是構建完善系統結構：對系統進行分解，將大系統分解為若乾子系統，子系統分解為若干軟體組件，並說明子系統之間的靜態和動態介面，每個子系統可以由用例模型、分析模型、設計模型、測試模型表示。軟體系統結構的兩種方式：層次、塊狀
層次結構：系統、子系統、模塊、組件（同一層之間具有獨立性）；
塊狀結構：相互之間弱耦合
系統的組成部分：
問題論域：業務相關類和對象(OOA的重點)；
人機界面：窗口、菜單、按鈕、命令等等；
數據管理：數據管理方法、邏輯物理結構、操作對象類；
任務管理：任務協調和管理進程；
第三步是利用「4＋1」視圖描述系統架構：用例視圖及劇本；說明體系結構的設計視圖；以模塊形式組成包和層包含概要實現模型的實現視圖；說明進程與線程及其架構、分配和相互交互關系的過程視圖；說明系統在操作平台上的物理節點和其上的任務分配的配置視圖。在RUP中還有可選的數據視圖。
第四步是性能優化（速度、資源、內存）、模型清晰化、簡單化（簡單就是享受）。
六、概要設計的原則
總體原則和方法：由粗到細的原則，互相結合的原則，定性分析和定量分析相結合的方法，分解和協調的方法和模型化方法。
要系統考慮系統的一般性、關聯性、整體性和層次性。
分解協調：目的是為了創造更好的系統。系統分解是指將一個復雜的系統分解為若干個子系統，系統協調一是系統內協調，即根據系統的總結構、總功能、總任務和總目標的要求，使各個子系統之間互相協調配合，在各個子系統局部優化基礎上，通過內部平衡的協調控制，實現系統的整體優化；
屏蔽抽象：從簡單的框架開始，隱含細節；
一致性：統一的規范、統一的標准、統一的文件模式；
每個模塊應當有一個統一命名的容易理解的名字；
編碼：由外向內（界面－>核心）；
面向用戶：概要設計是對於按鈕按下後系統「怎麼做」的簡要說明；
模塊、組件的充分獨立性、封閉性；
同時考慮靜態結構與動態運行；
每個邏輯對象都應當說明其所處物理對象（非一一對應）；
每個物理對象都有合適的開發人員，並且利於分工與組裝。（詳細說明見本人另一篇文章：系統構架設計應考慮的因素）；
確立每個構架視圖的整體結構：視圖的詳細組織結構、元素的分組以及這些主要分組之間的介面；
軟體構架與使用的技術平台密切相關，目前常用的平台有J2EE、.NET、CORBA等等，因此具體的軟體構架人員應當具備使用這些平台的軟體開發經驗；
通過需求功能與設計模塊之間的列表對應，檢查每個需求功能是否都有相應的模塊來實現，保證需求功能的可追溯性和需求實現（模塊）的完整性，同時可以檢查重復和不必要的模塊。
在需求調研分析過程中對業務處理過程了解的完整性和准確性非常重要。調查了解清楚所有的業務流程才能設計出適合各流程業務節點用戶業務特點和習慣的軟體，使開發出來的軟體更受歡迎。當然在進行軟體概要設計時，要盡量排除業務流程的制約，即把流程中的各項業務結點工作作為獨立的對象，設計成獨立的模塊，充分考慮他們與其他各種業務對象模塊的介面，在流程之間通過業務對象模塊的相互調用實現各種業務，這樣，在業務流程發生有限的變化時（每個業務模塊本身的業務邏輯沒有變的情況下），就能夠比較方便地修改系統程序模塊間的調用關系而實現新的需求。如果這種調用關系被設計成存儲在配置庫的數據字典里，則連程序代碼都不用修改，只需修改數據字典里的模塊調用規則即可。
七、概要設計的重要輸出
編碼規范：信息形式、介面規約、命名規則；
物理模型：組件圖、配置圖；
不同角度的構架視圖：用例視圖、邏輯視圖、進程視圖、部署視圖、實施視圖、數據視圖（可選）；
系統總體布局：哪些部分組成、各部分在物理上、邏輯上的相互關系；
兩個不可忽視的輸出：
與需求功能的關系：對於需求中的每一個功能，用哪一層、哪個模塊、哪個類、哪個對象來實現（一對多關系）；反過來，應當說明將要創建的系統每一層、每個模塊、每個對象、每一個類「做什麼」，他們是為了幫助實現哪些功能（一對多關系）。（需求的顆粒度在一開始往往是比較粗的，因此根據功能點對於整體項目規模的估計或得到項目WBS其誤差范圍也是比較大的。更為重要的原因是，需求往往不是編碼工作分解的准確依據，因為一個需求的功能點可能對應多個代碼模塊，而多個需求的功能點也可能只對應一個或少數代碼模塊，同時還有軟體復用等因素要考慮，因此只有在概要設計完成以後才能准確地得到詳細設計或編碼階段的二次 WBS，並估計較為准確的整體項目規模。）
邏輯與物理位置：每個對象在邏輯上分別落在哪一層、哪個模塊、哪個類；在物理上每個模塊、每個對象、每一個類放在哪個應用伺服器或客戶端的哪個目錄、哪個文件（庫），或者是建立在資料庫管理系統中的什麼東東（過程、函數、視圖、觸發器等等）。
八、結構化與面向對象方法特點比較
1. 從概念方面看，結構化軟體是功能的集合，通過模塊以及模塊和模塊之間的分層調用關系實現；面向對象軟體是事物的集合，通過對象以及對象和對象之間的通訊聯系實現；
2. 從構成方面看，結構化軟體＝過程＋數據，以過程為中心；面向對象軟體＝（數據＋相應操作）的封裝，以數據為中心；
3. 從運行控制方面看，結構化軟體採用順序處理方式，由過程驅動控制；面向對象軟體採用互動式、並行處理方式，由消息驅動控制；
4. 從開發方面看，結構化方法的工作重點是設計；面向對象方法的工作重點是分析；但是，在結構化方法中，分析階段和設計階段採用了不相吻合的表達方式，需要把在分析階段採用的具有網路特徵的數據流圖轉換為設計階段採用的具有分層特徵的結構圖，在面向對象方法中則不存在這一問題。
5. 從應用方面看，相對而言，結構化方法更加適合數據類型比較簡單的數值計算和數據統計管理軟體的開發；面向對象方法更加適合大型復雜的人機互動式軟體和數據統計管理軟體的開發；
參考文獻：
《實用軟體工程》第二版，鄭人傑、殷人昆、陶永雷等著
《微軟項目：求生法則》Steve McConnell著，余孟學譯
《軟體工程：實踐者的研究方法》（第5版）Roger S.Pressman著
《軟體構架實踐》SEI軟體工程譯叢，林·巴斯著
《RUP2000》電子版；
《UML與系統分析設計》張龍祥著；
《面向對象的分析與設計》楊正甫著；

㈡ 系統架構文檔怎麼寫

你這不是系統架構文檔,而是概要設計文檔和詳細設計文檔.

㈢ 軟體工程 關於教學管理系統的體系結構設計

這不是分的問題

㈣ 一般系統結構理論的參考文獻

[1] Fuyong Lin, et al., 2013. Developing an organization design framework and sample based on the total relationship flow management theorems, IEEE Transactions on Systems, Man and Cybernetics: Systems, Vol. 43, No. 6, 2013: 1466-1476
[2]林福永，2012，錢學森系統科學思想及其形式化發展，錢學森先生誕辰100周年紀念文集//中國科學院院士工作局編，科學出版社
[3] Fuyong Lin, T. C. Edwin Cheng. 2007a. The structural theory of general systems applied in management: total relationship flow management theorems. International Journal of General Systems, 36(6)
[4] Fuyong Lin, Kai Sun. 2007b. Network』s relationship flow-behavior theorems – the structural theory of general systems applied in network. Systems Engineering – Theory & Practice, 27(9)
[4] 林福永，孫凱，2007b，復雜網路關系流與行為關系定理——一般系統結構理論在復雜網路中的應用，系統工程理論與實踐，27(9)
[5] 張啟人，林福永，2002，復雜性科學中復雜性根源的研究及其結果，系統工程理論與實踐，22(10)
[6] 林福永，劉人懷，2001，復雜性科學中從簡單到復雜的自然法則的研究及其結果，自然雜志，23（4）
[7] 林福永，何敏，2000，一般系統結構理論，見：許國志院士等《系統科學與工程研究》，上海科技教育出版社
[8] Fuyong Lin, T. C. Edwin Cheng. 1999. The Principles and Laws of General Systems and Their Applications. Kybernetes - The International Journal of Systems & Cybernetics, 28(1)
[9] Fuyong Lin, T. C. Edwin Cheng. 1998a. The Structural Model of General Systems and its Proof. Kybernetes - The International Journal of Systems & Cybernetics, 27(9)
[10] 林福永，1998b，一般系統結構模型的數學分析及其結果——若干一般系統原理與規律，系統工程理論與實踐，18(12)
[11] 林福永，1998c，《一般系統結構理論》，暨南大學出版社
[12] 林福永，吳健中，1997a，一般系統結構理論及其應用（I），系統工程學報，12(3)
[13] 林福永，吳健中，1997b，一般系統結構理論及其應用（II），系統工程學報，12(4)
[14] 錢學森，1987，《論系統工程》，湖南科學技術出版社

㈤ ARM體系結構與編程的參考文獻

1. KaiHwang著.王鼎興，沈美明等譯《高等計算機系統結構並行性可擴展性可編程性》北京：清華大學出版社1995
2. 鄭緯民，湯志忠編著.《計算機系統結構》北京：清華大學出版社1998
3. NucleusPLUSReferencemanual.AcceleratedTechnology
4. L7200-05SDB-HWusersmanual.LinkUpSystemsCorporation2000
5. L7210DataBookRev1_2.LinkUpSystemsCorporation2000
6. DDI0100E_ARM_ARM.ARMLimited2000
7. DUI0068B_ADS1_2_Assembler.ARMLimited2001
8. DUI0151A_ADS1_2_LinkUt.ARMLimited2001
9. DUI0067D_ADS1_2_CompLib.ARMLimited2001
10. DUI0065D_ADS1_2_CodeWarrior.ARMLimited2001
11. DUI0058D_ADS1_2_DebugTarg.ARMLimited2001
12. DDI0192A_720T_R3.ARMLimited2000
13. DAI0048A_scatterload.ARMLimited1998
14. AdamCaly.n.Motorola,Inc.
15. DennisEdwards.ExecutingOutofROM.2002EmbeddedSystemsConference,SanFrancisco

㈥ 軟體體系結構設計的目錄

第一篇基礎篇：軟體體系結構的理論
第1章緒論1.1軟體體系結構的概念演化
1.1.1軟體體系結構的定義
1.1.2軟體體系結構的理論基礎
1.2軟體體系結構形式化方法概述
1.2.1基於CHAM的體系結構形式規約
1.2.2基於Z語言的體系結構形式規約
1.2.3基於一階邏輯的體系結構形式規約
1.2.4基於圖論的體系結構形式規約
1.2.5目前形式化方法存在的問題
1.3軟體體系結構描述語言概述
1.4軟體質量與質量模型
思考題
第2章軟體建模的基礎
2.1一個簡單例子
2.2面向對象特性
2.2.1封裝性
2.2.2繼承性
2.2.3多態性
2.3介面
2.4設計原則
2.4.1SRP單一職責原則
2.4.2OCP開閉原則
2.4.3LSP里氏替換原則
2.4.4ISP介面分離原則
2.4.5DIP依賴倒置原則
2.5UML2的各種圖
2.6需求建模：用例
2.6.1一個用例圖例子
2.6.2用例與參與者
2.6.3用例圖
2.6.4用例間關系
2.6.5用例對需求建模
2.7基本結構建模
2.7.1一個類圖例子
2.7.2性質
2.7.3對象圖
2.7.4操作
2.7.5介面
2.7.6關系
2.7.7關系建模
2.7.8類圖
2.8高級結構建模
2.8.1公共擴展機制
2.8.2包和包圖
2.8.3復合結構
2.8.4模板
2.9Kruchten4+1模型描述軟體體系結構
2.9.1邏輯視圖：面向對象的分解
2.9.2過程視圖：過程分解
2.9.3開發視圖：子系統分解
2.9.4物理視圖：從軟體到硬體的映射
2.9.5場景視圖：匯總
2.9.6視圖間的交流
2.9.7模型的迭代過程和軟體文檔
思考題
第3章軟體體系結構的形式化
3.1軟體的生命周期
3.2基於抽象代數的形式化方法
3.2.1構件
3.2.2連接件
3.2.3軟體體系結構
3.2.4軟體體系結構關系
3.2.5軟體體系結構範式
3.3基於粒度計算的形式化方法
3.3.1軟體體系結構演化
3.3.2屬性合成和跟蹤
3.3.3軟體體系結構多視圖表達及集成
3.3.4軟體體系結構風格和軟體體系結構風格發現
3.4*基於π演算的形式化方法
3.4.1π演算基本語法
3.4.2π演算約簡關系
3.4.3π演算遷移關系
3.5*動態軟體體系結構的形式化描述：化學抽象機
3.5.1化學抽象機模型
3.5.2軟體體系結構描述
思考題
第4章軟體體系結構的風格
4.1管道和過濾器風格
4.2倉庫風格和黑板風格
4.3事件驅動風格
4.4客戶機?分配器?伺服器風格
4.5分層系統風格
4.6解釋器
4.7面向服務的體系結構
4.7.1面向服務體系結構中的組成元素
4.7.2面向服務體系結構的設計原則
4.8過程式控制制環路模式
思考題
第5章體系結構描述語言
5.1典型ADL
5.1.1C2概述
5.1.2Darwin與Wright概述
5.1.3ACME概述
5.1.4UniCon概述
5.1.5Aesop概述
5.1.6Rapide概述
5.1.7MetaH
5.1.8SADL概述
5.2πADL的概述
5.2.1πADL體系結構描述框架
5.2.2πADL體系結構風格描述方法
5.3πADL體系結構行為規約
思考題
第6章軟體質量建模方法
6.1軟體質量建模與分析
6.1.1風險分析的基本概念
6.1.2風險分析的基本方法
6.1.3圖形化建模語言
6.2實證分析：軟體體系結構的質量
6.2.1地面智能機器人的軟體系統
6.2.2解決方案1：過程式控制制環路模式
6.2.3解決方案2：分層架構模式
6.2.4解決方案3：基於事件驅動的隱式調用模式
6.2.5解決方案4：黑板體系模式
6.2.6解決方案比較
思考題
第7章設計模式
7.1設計模式概述
7.2設計模式的分類
7.3創建型的設計模式
7.3.1Factory
7.3.2Prototype
7.3.3Builder
7.3.4Singleton
7.3.5Adapter
思考題
第8章戰場環境中自適應服務的軟體組合框架
8.1服務的描述與特徵
8.1.1服務模型
8.1.2服務事務處理
8.2TSCF服務組合框架
8.2.1TSCF框架
8.2.2服務代理設計
8.2.3服務組合協調
8.3服務調度流程式控制制的應用實現
8.4小結
思考題
第二篇軟體復用與構件庫的設計
第9章構件庫研究現狀
第10章軟體復用概述
第11章構件技術
第12章Web構件庫實現
第三篇軟體規模的度量
第13章軟體規模度量研究現狀
第14章FPA方法
第15章FPA方法的實際應用及其不足
第16章FPA方法的改進
第17章改進後FPA方法的應用及實例試驗
第四篇軟體的性能抗衰
第18章軟體的性能問題與抗衰技術18.1軟體性能衰退
第19章新型軟體抗衰策略
第20章細粒度軟體抗衰策略研究
第21章細粒度重啟技術研究
第22章細粒度軟體抗衰策略模型研究
附錄A縮略詞及中英文詞彙對照附錄B軟體體系結構支持工具參考文獻
……

㈦ 急用畢業論文文獻：一種基於Java技術的網路管理軟體的設計方案 的參考文獻 要近幾年的。。高手們速度了。

魏勇. 一種基於Java技術的網路管理軟體的設計方案[J]. 矽谷，2010，（20）：83.
雷明劍. Java Applet技術在網路管理中的研究及應用[D]. 重慶：重慶大學，2007.
許曉寧. Java Native Interface應用研究[J];計算機科學，2006，（10）：295-296，299.
李天科. 基於Web網路管理體系結構[J].農業網路信息，2006，（06）：67-69.
丁文學,蔡瑞英. 基於CORBA的XML映射中間件研究[J]. 微處理機，2009，（02）：45-48，52.
朱玉，張研. 一種基於Java技術的網路管理軟體的設計方案[J]. 微計算機信息，2005，（14）：57-59, 157.

以上應該差不多了，一篇論文至少要有3-5條參考文獻。

㈧ 一般參考文獻後中著作後面有[R][J][D][M]等符號代表什麼詳細點

參考文獻的著作來中R代表科技報自告，J代表期刊，D代表學位論文，M代表專著。

參考文獻類型及文獻類型，根據GB3469-83《文獻類型與文獻載體代碼》規定，以單字母方式標識，主要有：

專著M ； 報紙N ；期刊J ；專利文獻P；匯編G ；古籍O；技術標准S ；

學位論文D ；科技報告R；參考工具K ；檢索工具W；檔案B ；錄音帶A ；

圖表Q；唱片L；產品樣本X；錄相帶V；會議錄C；中譯文T；

樂譜I； 電影片Y；手稿H；微縮膠卷U ；幻燈片Z；微縮平片F；其他E。

(8)軟體體系結構參考文獻擴展閱讀

主要類型的參考文獻的格式為：

1、專著、論文集、學位論文、報告

[序號]主要責任者.文獻題名[文獻類型標識].出版地：出版者，出版年.起止頁碼（任選）.

2、報紙文章

[序號]主要責任者.文獻題名[J].刊名，年，卷（期）：起止頁碼.

3、專利文獻

[序號]專利所有者.專利題名[P].專利國別：專利號，出版日期.

㈨ 求一篇關於 軟體體系結構分析 的論文

軟體體系結構論文：一種面向方面軟體體系結構模型
摘 要: 為了分離軟體系統中的核心關注點和橫切關注點，通過引入面向方面軟體開發的思想設計了一種面向方面軟體體系結構模型，並詳細分析了該模型的三個基本構成單元，即構件、連接件和方面構件。最後通過一個網上支付實例驗證了該模型具有一定的理論意義和實用價值。
關鍵詞: 面向方面軟體體系結構;橫切關注點;構件;連接件;方面構件
20世紀60年代的軟體危機使得人們開始重視軟體工程的研究。起初，人們把軟體設計的重點放在數據結構和演算法的選擇上，然而隨著軟體系統規模越來越大，對總體的系統結構設計和規格說明變得異常重要。隨著軟體危機程度的加劇，軟體體系結構(software architecture)這一概念應運而生。軟體體系結構著眼於軟體系統的全局組織形式，在較高層次上把握系統各部分之間的內在聯系，將軟體開發的焦點從成百上千的代碼上轉移到粒度較大的體系結構元素及其交互的設計上。與傳統軟體技術相比，軟體體系結構理論的提出不僅有利於解決軟體系統日益增加的規模和復雜度的問題，有利於構件的重用，也有利於軟體生產率的提高。面向方面軟體開發(AOSD)認為系統是由核心關注點(corn concern)和橫切關注點(cross-cutting concern)有機地交織在一起而形成的。核心關注點是軟體要實現的主要功能和目標，橫切關注點是那些與核心關注點之間有橫切作用的關注點，如系統日誌、事務處理和許可權驗證等。AOSD通過分離系統的橫切關注點和核心關注點，使得系統的設計和維護變得容易很多。
Extremara大學的Navasa等人［1］在2002年提出了將面向方面軟體開發技術引入到軟體體系結構的設計中，稱之為面向方面軟體體系結構(aspect oriented software architecture，AO-SA)，這樣能夠結合兩者的優點，但是並沒有給出構建面向方面軟體體系結構的詳細方法。
盡管目前對於面向方面軟體體系結構這個概念尚未形成統一的認識，但是一般認為面向方面軟體體系結構在傳統軟體體系結構基礎上增加了方面構件(aspect component)這一新的構成單元，通過方面構件來封裝系統的橫切關注點。目前國內外對於面向方面軟體體系模型的研究還相對較少，對它的構成單元模型的研究更少，通常只關注方面構件這一構成單元。方面構件最早是由Lieberherr等人［2］提出的，它是在自適應可插拔構件(adaptive plug and play component，APPC)基礎之上通過引入面向方面編程(AOP)思想擴展一個可更改的介面而形成的，但它關於請求介面和服務介面的定義很模糊，未能給出一個清晰的方面構件模型。Pawlak等人［3］提出了一個面向方面的框架，該框架主要包含了一個方面構件模型———Java方面構件(Java aspect component，JAC)，但該方面構件模型僅包含了切點(pointcut)，並把AOP中裝備(advice)集成到了切點的表達式中，它主要從實現的角度進行了闡述，並沒有給出詳細的方面構件模型。本文沒有隻關注面向方面軟體體系結構中方面構件這一構成單元模型，還詳細分析了它的另外兩個構成單元，即構件和連接件，因為面向方面軟體體系結構各部分之間是相互關聯的。
1面向方面軟體體系結構相關概念
面向方面軟體體系結構涉及諸多概念，以下將分別介紹。軟體體系結構在軟體工程領域有著廣泛的影響，但當前仍未形成一個統一的、標準的定義。目前國內外普遍認可的看法是軟體體系結構包含構件、連接件和約束［4］。其中約束描述了體系結構配置和拓撲的要求，確定了體系結構的構件與連接件的連接關系。這樣就可以把軟體體系結構寫成
軟體體系結構(software architecture)=構件(components)+
連接件(connectors)+約束(constraints)
構件是軟體體系結構的基本元素之一。一般認為，構件是指具有一定功能、可明確辨識的軟體單位，並且具備語義完整、語法正確、有可重用價值的特點，然而目前對於構件的具體結構及構成並沒有一個統一的標准［5］，而且一些主要的構件技術也沒有使用相同的構件類型。另外，當前被廣泛接受的構件定義並不包含具體的軟體構件模型(software component model)。例如，Szyperski等人［6］給出了軟體構件一個很有名的定義:軟體構件是一個僅帶特定契約介面和顯式語境依賴的結構單位，它可以獨立部署，易於第三方整合。但是關於軟體構件模型有一個被普遍接受的觀點是:軟體構件是一個具有服務提供和服務請求功能的軟體單元［7］。
連接件是軟體體系結構另一個基本的構成元素，是用來建立構件間交互以及支配這些交互規則的構造模塊。連接件最先是由Shaw［8］提出來的，她建議把連接件作為軟體體系結構中第一類實體，用來表示普通構件之間的交互關系。目前對於連接件尚未形成統一的認識，盡管在軟體體系結構中強調了連接件存在的必要性，但是關於連接件模型的研究還很少，連接件的實際應用還不成熟。
面向方面軟體體系結構在傳統軟體體系結構的基礎上增加了方面構件單元。通常認為，方面構件是封裝了系統橫切關注點的一類特殊的構件。目前關於方面構件模型的研究還處於起步階段。
2面向方面軟體體系結構模型
由於傳統軟體體系結構模型包含構件、連接件和約束，而面向方面軟體體系結構是在傳統軟體體系結構的基礎之上擴展了方面構件，所以面向方面軟體體系模型結構包含構件、連接件、方面構件和約束。其中約束描述了面向方面體系結構配置和拓撲的要求，確定了體系結構的構件、連接件和方面構件之間的連接關系，而構件、連接件、方面構件是它的三個基本的構成單元。以下對這三個構成單元的模型進行詳細的設計。
2.1構件模型
構件模型由以下幾個要素構成(圖1):
(a)埠。
構件的服務請求和服務提供功能是通過埠來實現的。埠是構件與外部環境進行交互的惟一通道。一般的構件模型通常採用兩種埠，即雙向埠和單向埠。在使用雙向埠的構件模型中，服務請求和服務提供功能可以在同一個埠中實現。本文中的構件模型使用單向埠，此種埠分為請求埠和服務埠兩種類型。
(a)服務埠。構件通過服務埠向其他構件提供服務。構件通過服務埠向其他構件的請求消息進行應答，返回響應消息。每個服務埠對應一個介面。
(b)請求埠。構件通過請求埠向其他構件請求服務。構件為了實現自己的業務功能，需要通過請求埠向其他構件發送請求消息。每個服務埠也對應一個介面。
(b)介面。
它定義了一個到多個業務功能。這些業務功能由服務埠進行提供，並由請求埠進行使用。一個介面限定了一個特定埠可以進行的交互功能，介面是構件間交互的契約。通常的介面類型有:Java Interface、WSDL 1．1 portTypes和WSDL 2．0 Interfaces等，也可以自定義介面類型。
(c)屬性。
與類或對象相似，構件也具有屬性，屬性可以在構件使用前進行配置，它能夠反映構件在交互過程中狀態的變化。
2.2連接件模型
連接件是用來建立構件間交互以及支配這些交互規則的體系結構構造模塊。連接件為構件間信息交互提供傳輸和路由服務。在最簡單的情況下，構件之間可以直接完成交互，這時體系結構中的連接件就退化為直接連接。在更為復雜的情況下，構件間交互的處理和維持都需要連接件來實現。對於構件而言，連接件是構件的粘合劑，是構件交互的實現，也可以看做是一種特殊的構件［8］。與構件相似，連接件也具有埠。連接件的埠可分為兩種類型，即源埠(source port)和目標埠(target port)。源埠用於接收構件請求埠中的消息，目標埠用於向構件服務埠中輸入消息。連接件通常需要使用一種合適的綁定(binding)機制，構件的請求埠使用這種綁定機制來描述服務請求的方法，構件的服務埠也使用這種機制來描述構件進行請求的方式。常用的綁定機制有:WebService Binding和JMS Binding等，也可以自定義綁定機制。與構件一樣，連接件也具有屬性，來表示構件間交互的狀態變化，如圖2所示。

2.3復合構件模型
構件可分為兩種，即原子構件和復合構件。前者是不可再分的構件。後者是可再分構件，它封裝了若干個子構件。子構件間通過連接件相互連接，且子構件的埠也可以暴露成為復合構件的埠，子構件也可能是復合構件。如圖3所示:復合構件A包含兩個子構件B和D，子構件B和D通過連接件C進行相連，構件B的服務埠E暴露成為復合構件A的服務埠F，其請求埠G暴露成為A的請求埠H。
2.4方面構件模型
方面構件是面向方面軟體體系結構的一個核心的構成單元，它封裝了橫切關注點，這是與傳統軟體體系結構最大的不同之處。圖4給出了方面構件模型，與普通構件一樣，方面構件也有服務埠和請求埠以及屬性，但是它還有普通構件所沒有的方面埠。當一個構件具有一個方面埠時，即可認為此構件就是方面構件。一個方面埠中包含若干個方面，這與一般面向方面編程(AOP)技術中方面概念有所不同。面向方面編程具有以下四個基本概念:方面(aspect)、連接點(joinpoint)、通知(advice)和切點(pointcut)。連接點是應用程序執行過程一個定義明確的位置，如方法調用是一種典型的連接點。切點是一系列連接點的集合，是方面的作用點。通知表述了在切點所選定的連接點處要執行的動作，常見通知類型有before、around和after等，分表代表在連接點之前、連接點附近和連接點之後執行相應的通知代碼。方面是用來描述和實現橫切關注點的基本單位，由切點和通知構成。方面埠中的方面橫切關注的是構件，這與一般AOP(如AspectJ)橫切關注的對象(object)不同，由於構件能夠表達對象所不能表達的請求服務的能力［9］，這使得方面埠中方面所採用的連接點模型和切點語言具有很大的不同。

2.4.1連接點模型
該連接點模型包含兩種不同類型的連接點，即構件服務埠中的服務提供操作和請求埠的服務請求操作。由於構件的內部結構通常被視為黑盒，因此連接點模型應該僅考慮構件的外部可見元素，如構件請求埠和服務埠中的服務操作。如果連接點模型包含構件的屬性，那麼它將會破壞構件的分裝性。
2.4.2切點語言
用來選用連接點的切點語言基於切點表達式，表1給出了切點的五個組成部分，即component、jp_type、port、interface和service，然後分別對其進行了說明。其中，jp_type代表選用的連接點類型，可以是請求埠中的服務、服務埠中的服務或所有埠中的服務，詳細如表1。表2給出了切點語言的一些例子，其中正則表達式基於java．util．regexp包。

2.5面向方面軟體體系結構模型
面向方面軟體體系結構由構件、連接件、方面構件組成，詳細請參見圖6。

3基於面向方面軟體體系結構模型的網上支付實例
近年來，網上購物發展迅速，網上支付是消費者主要的支付手段之一，圖7給出了基於面向方面軟體體系結構的網上支付模型，它由四個原子構件，即一個復合構件、兩個方面構件和三個連接件組成。其中WebClientComponent代表客戶端構件，它可以向網上銀行構件WebBankComponent請求AccountService()服務，該服務有三個參數，即username、password、cost，分別對應於用戶的網上銀行賬戶名、密碼及購買商品的消費金額。
〈component name="WebClientComponent"〉〈required．port name="WebClientRequest"〉
〈java．interface interface="AccountServiceInterface"〉〈service name="AccountService()"〉
〈param name="username"type="string"/〉
〈param name="password"type="string"/〉
〈param name="cost"type="float"/〉
〈/service〉〈/java．interface〉
〈/required．port〉
〈/component〉
連接件AccountServiceConnector用於連接客戶端構件和網上銀行構件，它採用WebServiceBinding綁定機制。
〈connector name="AccountServiceConnector"binding="WebServi-ceBinding"/〉
〈source name="S"/〉〈target name="T"〉
〈/connector〉
〈connect．source from="WebClientComponent．WebClientRequest"to="S"/〉
〈connect．target from="T"to="WebBankComponent．Bank-Re-sponse"/〉
網上銀行構件是一個復合構件，由賬戶服務構件Account-ServiceComponent、賬戶資料庫連接件AccountDBConnector和賬戶資料庫構件AccountDBComponent組裝而成。其中該復合構件的服務埠也使用介面AccountServiceInterface，這是為了兼容客戶端構件請求埠使用的介面。
身份驗證構件AuthenticationComponent用於驗證用戶的身份信息，它通過UserInfoConnector連接件訪問用戶信息資料庫構件UserInfoDBComponent。
pointcut="WebBankComponent;BankResponse;AccountServiceInterface;AccountService()"
是該方面構件的方面埠中使用切點的表達式。
為了保證資料庫構件UserInfoDBComponent和AccountDB-Component的安全性，方面構件SecurityComponent使用方面埠Security監視這兩個構件的服務埠，使得在這兩個構件服務調用之前增加日誌和事務功能，而日誌和事務功能在系統中通常表現為橫切關注點，面向方面軟體體系結構能夠對它進行很好的封裝，便於設計和維護。
〈aspect．component name="SecurityComponent"〉〈aspect．port name="Security"〉〈aspect〉〈pointcut="UserInfoDBComponent;UserInfoResponse;*;*|Ac-countDBComponent;AccountDBResponse;*;*"/〉〈advice．role="before"action="Log()"/〉〈advice．role="before"action="Transaction()"/〉〈/aspect〉〈/aspect．port〉〈required．port name="UserInfoRequest"/〉〈/aspect．component〉
4結束語
本文給出了一種面向方面軟體體系結構模型，詳細設計了它的三個基本構成單元模型，即構件、連接件和方面構件;最後通過一個網上支付實例驗證了該模型有效性和實用性，為面向方面軟體體系結構的實際應用奠定了一定的基礎。筆者將繼續完善該模型的相關理論，研究面向方面軟體體系結構的工程化應用方法。
參考文獻:
［1］FABRESSE L，DONY C，HUCHARD M．Foundations of a simpleand unified component-oriented language［J］．Journal of ComputerLanguages，Systems＆Structures，2008，34(2-3):130-149．
［2］LIEBERHERR K，LORENZ D，MEZINI M．Programming with as-pectual components，T R NU-CSS-99-01［R］．［S．l．］:NoutheastamUniversity，1999．
［3］PAWLAK R，SERNTURIER L，DUCHIEN L D，et al．JAC:an as-pect-based distributed dynamic framework［J］．Software Practiceand Experiences，2004，34(12):1119-1148．
［4］李千目．軟體體系結構設計［M］．北京:清華大學出版社，2008．
［5］馬亮，孫春艷．軟體構件概念的變遷［J］．計算機科學，2002，29(4):28-30．
［6］SZYPERSKI C，GRUNTZ D，MURER S．Component software:be-yond object-oriented programming［M］．2nd ed．［S．l．］:Addison-Wesley，2002．
［7］LAU K K，WANG Z．Software component models［J］．IEEE TransSoft Eng，2007，33(10):709-724．
［8］SHAW M．Procere calls are the assembly language of software in-terconnection:connectors deserve first-class status［C］//Proc of InICSE Workshop on Studies of Software Design．1993:17-32．
［9］NAVASA A，PREZ M A，MURILLO J M，et al．Aspect orientedsoftware architecture:a structural perspective［C］//Proc of Workshopon Early Aspects．2002．

㈩ 軟體體系結構的圖書

作者：(美)肖
出版社：清華大學出版社
出版時間： 2007
ISBN: 9787302145509
開本：16
定價: 29.80 元 軟體體系結構作為從軟體設計抽象出來的一門新興學科，目前已經成為軟體工程一個重要研究領域。本書作者MaryShaw和DavidGarlan作為軟體體系結構最早的研究者，在體系結構領域做出了大量先導性的工作。
本書共有8章：緒論、軟體體系結構風格、案例研究、共享信息系統、軟體體系結構描述、軟體體系結構的分析與評估、特定領域的軟體體系結構和流行的軟體體系結構等。本書第1-4章主要譯自MaryShaw和DavidGarlan的著作。根據目前軟體體系結構的現狀、以及編譯者多年的教學實踐經驗，在第1章和第5章加入了部分新的內容，並重新編寫了第6章、第7章和第8章。其中第6，7章是在參考了大量相關研究的基礎上，結合作者在圖書館領域的親身實踐編寫的。
本書可以作為計算機專業研究生和高年級本科生的軟體體系結構課程的教材或參考書，也可作為軟體開發人員的參考手冊。 第1章緒論
1.1什麼是軟體體系結構
1.2軟體體系結構研究的內容和范疇
1.3體系結構設計原則
1.4軟體體系結構研究的現狀
1.5全書的安排
第2章體系結構風格
2.1體系結構風格
2.2管道過濾器
2.3數據抽象和面向對象組織結構
2.4事件驅動，隱式調用
2.5分層系統
2.6知識庫
2.7解釋器
2.8過程式控制制
2.9其他常見的體系結構
2.10異構體系結構
第3章案例研究
3.1上下文關鍵字
3.2儀器軟體
3.3移動機器人
3.4定速巡航控制
3.5復合混合風格的三個案例
第4章共享信息系統
第5章軟體體系結構描述
第6章軟體體系結構的分析與評估
第7章特定領域的軟體體系結構
第8章流行的軟體體系結構
參考文獻
bn-qiange