論使用復用設計1、引言復用是活動，而不是對象。在創建軟件相關的系統的語境中，復用僅僅是非常簡單的任何過程，該過程通過復用來自以前開發工作的某些東西來生產(或幫助生產)一個系統。那么，唯一的問題是：復用什么、什么是導致成功復用的過程。在軟件工程的范圍內，復用既是舊概念，也是新概念。程序員從最早的計算時代已開始復用概念、對象、論據、抽象和過程，但是我們復用的途徑是特定的。本文對軟件復用的討論，將從以下四個方面進行：1）軟件工程師可以獲得一系列可復用的軟件制品，這些包括軟件的技術表示(例如，規約、體系結構模型、設計和代碼)、文檔、測試數據，甚至包括過程相關的任務(如，檢查技術)。2）復用過程包括兩個并發的子過程：領域工程和軟件工程。領域工程的目的是在特定應用領域中標識、構造、分類和傳播一組軟件制品。然后，軟件工程可在新系統開發中選取這些軟件制品作為復用。3）構件復用為軟件質量、開發者生產率、以及整個系統成本帶來了固有的收益，然而，在復用過程模型被廣泛地用于軟件產業前，必須克服很多障礙。4）對可復用構件的分析、設計技術采用和在良好的軟件工程實踐中使用的相同原則和概念。可復用構件應該在一個環境中設計，該環境為每個應用領域建立標準數據結構、接口協議和程序體系結構。2、可復用的軟件制品軟件復用不僅僅涉及源代碼，但是，還涉及多少東西呢？CaperJones定義了可作為復用候選的十種軟件制品：項目計劃。軟件項目計劃的基本結構和許多內容(例如，SQA計劃)均是可以跨項目復用的。這樣減少了用于制定計劃的時間，也減低了和建立進度表、風險分析和其他特征相關的不確定性。成本估計。因為經常不同項目中含有類似的功能，所以有可能在極少修改或不修改的情況下，復用對該功能的成本估計。體系結構。即使當考慮不同的應用領域時，也很少有截然不同的程序和數據體系結構。因此，有可能創建一組類屬的體系結構模板(例如，事務處理體系結構)，并將那些模板作為可復用的設計框架。需求模型和規約。類和對象的模型和規約是明顯的復用的候選者，此外，用傳統軟件工程方法開發的分析模型(例如，數據流圖)也是可復用的。設計。用傳統方法開發的體系結構、數據、接口和過程化設計是復用的候選者，更常見的是，系統和對象設計是可復用的。源代碼。驗證過的程序構件(用兼容的程序設計語言書寫的)是復用的候選者。用戶和技術文檔。即使特定的應用是不同的，也經常有可能復用用戶和技術文檔的大部分。用戶界面。可能是最廣泛被復用的軟件制品，GUI軟件經常被復用。因為它可占到一個應用的60％的代碼量，因此，復用的效果非常顯著。數據。在大多數經常被復用的軟件制品中，數據包括：內部表、列表和記錄結構，以及文件和完整的數據庫。測試用例。一旦設計或代碼構件將被復用，相關的測試用例應該“附屬于”它們。應該注意，復用可以擴展到上面所討論的可交付的軟件制品之外，它也包含了軟件工程過程中的元素。特定的分析建模方法、檢查技術、測試用例設計技術、質量保證過程、以及很多其他軟件工程實踐可以被“復用”，例如，如果某軟件項目組有效地應用凈室軟件工程方法，該方法可能適用于另一個項目。為了作出決定，有必要定義一組描述功能，它們使得潛在的凈室用戶能夠對其應用作出適當的決策。3、復用過程復用過程包括兩個并發的子過程：領域工程和軟件工程。3.1、領域工程領域工程的目的是標識、構造、分類和傳播一組軟件制品，它們對某特定應用領域中對現存的和未來的軟件系統具有很好適用性。其整體目標是建立相應的機制，以使得軟件工程師在工作于新的或現存的系統時可以分享這些軟件制品——復用它們。領域工程包括三個主要的活動——分析、構造和傳播。在第20章中已給出領域分析的概述，然而，本節中將再討論這個話題。領域構造和傳播將在本章以后幾節中討論。有人爭辯說“復用將消失，不是被消除，而是被集成”進軟件工程實踐之中，隨著復用被更多的強調，人們相信在下個十年領域工程將變得和軟件工程一樣重要。3.1.1、領域分析過程在面向對象軟件工程范圍內領域分析的方法，過程中的步驟定義如下：1).定義將被研究的領域。2).分類從領域中抽出的物項。3).收集領域中有代表性的應用樣本。4).分析樣本中的每個應用。5).開發對象的分析模型。必須注意，領域分析適用于任意軟件工程范型，并且可以用于傳統的以及面向對象的軟件開發。Prieto－Diaz擴展了上面給出的領域分析的第二個步驟，建議了一個8步驟的標識和分類可復用軟件制品的方法：1).選擇特定的功能/對象。2).抽象功能/對象。3).定義分類法。4).標識公共特征。5).標識特定的關系。6).抽象關系。7).導出功能模型。8).定義領域語言。領域語言使得在領域中進行應用的規約及構造成為可能。雖然上面的步驟提供了一個有用的領域分析模型，但是它沒有提供幫助決定哪些軟件制品是復用候選的有用的指南。Hutchinson和Hindley提出了下面一組實際的問題，它們可以用作標識可復用軟件構件的指南：*構件功能對未來的實現工作是需要的嗎？*在領域中構件功能的公共性怎樣？*在領域中存在構件功能的重復嗎？*構件是否依賴于硬件？*在不同實現之間硬件是否保持不變？*硬件細節可被移動到另一個構件嗎？*設計為下面的實現進行過足夠的優化嗎？*我們能夠將一個不可復用的構件參數化以使其變成可復用的嗎？*構件是否可以僅僅經過少許修改就能夠在很多實現中復用嗎？*通過修改進行復用是可行的嗎？*某不可復用的構件能夠通過被分解以產生一組可復用構件嗎？*針對復用的構件分解是有效的嗎？關于領域分析的深入討論不在本書范圍之內，更多的信息可見。3.1.2、結構建模和結構點當使用領域分析時，分析員尋找在某領域中應用間的重復模式。結構化建模(Structuralmodeling)是一種基于模式的領域工程方法，應用該方法的前提假設是：每個應用領域有重復的模式(功能的、數據的和行為的)，它們具有可復用的潛在可能。Pollak和Rissman描述結構建模如下：結構模型由少量的用于表明清晰的交互模式的結構元素組成。使用結構模型的系統的體系結構通過多個由這些模型元素組成的東西來刻劃，這樣，在系統的體系結構單元間的復雜交互可以用在這些少量元素間的簡單交互模式來描述。每個應用領域可用一個結構模型來刻劃(例如，飛行器電子設備在細節上差異很大，但是在該領域的所有現代軟件具有相同的結構模型)，因此，結構模型是一種體系結構制品，它可以也應該在領域內所有應用中被復用。McMahon描述結構點(structurePoint)為：“在結構模型中的一個獨特構成物”，結構點有三個顯著的特征：1).一個結構點是一個抽象，它應該有有限數量的實例。用面向對象的行話來陳述，類層次的規模應是小的。此外，該抽象應該在領域中所有應用中不斷重現，否則，用于驗證、文檔化和傳播結構點所需的努力不可能是成本合算的。2).管理結構點的使用的規則應該是容易理解的。此外，結構點的接口應該相當簡單。3).結構點應該通過隱藏所有包含在結構點內部的復雜性而實現信息隱蔽，這會減少整個系統可被感知的復雜性。作為把結構點當作系統的體系結構模式的一個例子，考慮警報系統的軟件領域，該領域可能包含如SafeHome①這樣簡單的系統，或如工業過程警報系統這樣復雜的系統，然而，在每種情形，均可以遇到一組可以預測的結構模式：*界面，使用戶能夠和系統交互。*范圍設置機制，允許用戶設置將被測度的參數的范圍。*傳感器管理機制，和所有的監控傳感器通訊。*反應機制，對傳感器管理系統提供的輸入作出反應。*控制機制，使用戶能夠可以控制監控執行的方式。這些結構點中的每一個被集成到一個領域體系結構中。定義跨越一組不同的應用領域的類屬的結構點是可能的：*應用前端。GUI，包括所有菜單、面板、輸入和命令編輯設施。*數據庫。所有和應用領域相關的對象的倉庫。*計算引擎。操作數據的數值和非數值模型。*報告設施。產生所有種類的輸出的功能。*應用編輯器。根據用戶特定需要定制應用的機制。結構點已被建議作為在軟件成本估計中代碼行和功能點的替代物。4、構件復用關于創建可復用的軟件并沒有任何神奇之處。抽象、隱蔽、功能獨立性、求精、以及結構化程序設計等設計概念，連同面向對象方法、測試、SQA、以及正確性驗證方法——所有均對可復用軟件構件的創建有貢獻。本節中，我們將不重復討論這些話題，而是考慮特定于復用的問題，它們是對完整的軟件工程實踐的補充。4.1、為了復用的分析和設計數據、功能和行為模型(用一系列不同符號表示)可以被創建以描述特定應用必須完成的任務，書面的規約被用于描述這些模型并生成完整的需求描述。理想地，分析分析模型以確定模型中的那些指向現存的可復用軟件制品的元素。問題是以能夠導致“規約匹配”的形式從需求模型中抽取信息。Bellinzoni及其同事描述了一種針對面向對象系統的方法：構件被在不同的抽象層次定義和存儲為規約、設計和實現類——每個類是來自以前應用的某產品的工程化描述。規約知識——開發知識——被以復用建議(reuse-suggestion)類的形式存儲，它們包括對以構件的描述為基礎檢索可復用構件及檢索后組裝和剪裁構件的指導。使用自動化工具瀏覽構件庫，以試圖匹配當前規約中所標記的需求和那些為現存可復用構件(類)描述的需求。領域特征和關鍵詞被用于發現潛在的可復用構件。如果規約匹配生成符合當前應用需要的構件，設計者可從可復用構件庫中提取這些構件并將它們用于新系統的設計中。如果沒能找到設計構件，軟件工程師必須應用傳統的或面向對象的設計方法去創建它們。正是在這點——當設計者開始創建新的構件時——應該考慮為了復用的設計(DFR)。我們已經提到過，為了復用的設計需要軟件工程師應用已有的設計概念和原則，但是，也必須考慮應用領域的特征。Binder建議了作為為了復用的設計的基礎而應該考慮的一系列關鍵問題：標準數據。應該研究應用領域，并標識出標準的全局數據結構(例如，文件結構或完整的數據庫)，那么所有設計構件可以使用這些標準數據結構來刻劃。標準接口協議。應該建立三個層次的接口協議：模塊內接口的本質、外部的技術(非人)接口的設計、以及人機界面。程序模板。結構模型可以作為新程序的體系結構設計的模板。一旦已經建立了標準數據、接口和程序模板，則設計者有了一個可在其中創建設計的框架。符合這個框架的新的構件對以后的復用有更高的概率。4.2、構造方法和設計一樣，可復用軟件制品的構造依賴于本書中其他地方已經討論過的軟件工程方法，構造可以使用傳統的第三代語言、第四代語言和代碼生成器、可視化程序設計技術、或更高級的工具來完成。更高級的構造技術的一個有代表性例子是Netron公司開發Frame技術Netron方法定義了一組自適應的、稱作Frame的類屬構件。和對象一樣，Frame封裝數據和操作，但是，它擴展了對象的定義，它結合進了使軟件工程師能夠通過選擇、刪除、修改或重復那些構成該Frame的任意子構件而對Frame進行適應性修改的機制。可以通過組裝來自Frame層次的構件而構造應用。在該層次底部的Frame類似于在因子化體系結構中的工作者(worker)模塊，即，它們包含執行低層系統功能(例如，操作系統交互、接口構造、數據庫交互)的操作和數據結構；在Frame層次中層的Frame著重于和特定信息系統領域相關的功能(例如，事務處理、銀行業務、客戶服務)；在層次的頂部是“規約fream”，它的作用是作為“系統的主要藍圖和開發者創建來定義系統的唯一的Frame”。4.3、基于構件的開發當復用占據了一個應用開發的主導地位時，則構造方法有時被稱為基于構件的開發或構件軟件。如我們已經看到的，領域工程提供了基于構件的開發所需要的可復用構件庫。這些可復用構件中的某些是內部開發的，其他的可以從現存應用中抽取的，還有一些可以從第三方獲取。但是，我們如何創建一個具有一致結構的構件庫——它可以被一系列不同的內部和外部源查詢并且還可以被集成進在某應用領域內的任意系統？答案是對這樣的構件的標準的采用。4個“體系結構成分”將被用于實現基于構件的開發：數據交換模型。應該對所有的可復用構件定義使得用戶和應用間能夠交互和傳遞數據的機制(例如，拖和放、剪切和粘貼)。數據交換機制不僅應允許人和軟件、構件和構件間的數據傳遞，而且也應使得能夠在系統資源間進行數據傳遞(例如，將一個文件拖到某打印機圖符上以實現輸出)。自動化。應實現一系列工具、宏和腳本為可復用構件間的交互服務。結構化存儲。包含在“復合文檔”中的異質數據(例如，圖形數據、聲音、文本和數值數據)應該被作為單獨的數據結構來組織和訪問，而不是作為一組分開的文件。“結構化數據維持了嵌套結構的一個描述性索引，使得應用可以自由地進行導航瀏覽以定位、創建或編輯個體數據內容，就象終端用戶直接操作一樣”。底層對象模型。對象模型保證在不同平臺上用不同程序設計語言開發的構件可以互操作，即，對象必須能夠跨網絡進行通信。為了達到這個目標，對象模型定義了構件互操作標準，該標準是語言獨立的，并使用接口定義語言(IDL)來定義。因為復用對軟件產業的潛在影響非常巨大，一些主要的公司和產業聯盟①已經提出了對構件軟件的建議標準：OpenDoc。主要技術公司(包括IBM、Apple、和Novell)的一個聯盟已經提出了復合文檔和構件軟件的標準OPenDoc。該標準定義了為使得由某開發者提供的構件能夠和另一個開發者提供的構件相互操作而必須實現的服務、控制基礎設施、和體系結構。OMG/CORBA。對象管理組織發布了公共對象請求代理體系結構(OMG/CORBA)。一個對象請求代理(ORB)提供了一系列服務，它們使得可復用構件(對象)可以和其他構件通信，而不管它們在系統中的位置。當用OMG/CORBA標準建立構件時，那些構件在某系統內的集成(沒有修改)可以得到保證。使用客戶/服務器的比喻，在客戶端應用中的對象向ORB服務器請求一個或多個服務，請求是通過IDL或在運行時動態地進行的。一個接口池包含了所有關于服務請求和回答格式的信息。OLE2.0。微軟開發了一個構件對象模型(COM)，它提供了對在單個應用中使用不同廠商生產的對象的規約。對象連接和嵌入(OLE)是COM的一部分，定義了可復用構件的標準結構。OLE已成為微軟操作系統(Windows95、WindowsNT)的一部分。這些標準中哪一個將在產業中占據支配地位？這在當前是不容易回答的問題。當前OLE被用得更廣一些(由于基于Windows應用的廣泛使用)，但是，很多OMG/CORBA工具和開發環境正在被引入。5、分類和檢索構件考慮一個大的大學圖書館，成千上萬的書籍、期刊和其他信息資源是可用的。但是為了訪問這些資源，必須有合適的分類模式。為了在這些大量的信息中導航瀏覽，圖書館管理者定義了一種分類模式，它包括分類碼、關鍵詞、作者名、以及其他索引條目，所有這些使得用戶可以快速和方便地找到所需資源。現在考慮一個大的構件倉庫，其中存放了成千上萬的可復用構件。但是，軟件工程師如何找到他所需要的構件呢？為了回答這個問題，又出現了另一個問題：我們如何以無二義的、可分類的術語來描述軟件構件？這些是困難的問題，至今還沒有確定性的答案。在本節中，我們探討當前的研究方向，這將使得未來的軟件工程師可以導航瀏覽復用庫。5.1、描述可復用構件可以用很多方式來描述可復用軟件構件，但是理想的描述包括TracZ提出的3C模型——概念(concePt)、內容(content)和語境(context)。軟件構件的概念是“對構件做什么的描述”。構件的接口被完整地描述，而且語義——表示在前置條件后置條件的語境中——被標識。概念將傳達構件的意圖。構件的內容描述概念如何被實現。在本質上，內容是對一般用戶隱蔽的信息，只有那些企圖修改該構件的人才需要了解的信息。語境將可復用軟件構件放置到其應用的領域中。即，通過刻劃概念的、操作的和實現的特征，語境使得軟件工程師能夠發現適當的構件以滿足應用需求。為了可用在實際環境中，概念、內容和語境必須被轉換為具體的規約模式。已有很多的文章涉及可復用構件的分類模式。①所提出的方法可以分為三大類：圖書館和信息科學方法、人工智能方法、以及超文本系統。目前為止，絕大部分研究工作建議使用圖書館科學方法進行構件分類。大多數軟件構件分類模式可歸為如下的三類：1)枚舉分類(EnumeratedClassification)。通過定義一個層次結構來描述構件，在該層次中定義軟件構件的類以及不同層次的子類。實際的構件被羅列在枚舉層次的任何路徑的最低層，例如，對窗口操作的枚舉層次可能是：windowoperationsdisplayopenmenu-basedOpenWindowsystem－basedsysWindowcloseviapointer…resizeviacommandsetWindowSize，stdResize，shrinkwindowviadragpullwindow，stretchWindowup/downshuffle…move…close…枚舉分類模式的層次結構使得它易于理解和使用，然而，在建立層次之前，必須進行領域工程以獲得在層次中適當的項的足夠的信息。刻面分類(FacetedClassification)。分析領域，并標識出一組基本的描述特征，這些特征，稱為刻面，被根據其重要性區分優先次序并被聯系到構件。刻面可以描述構件執行的功能、被操作的數據、構件應用的語境或任意其他特征。描述構件的刻面的集合稱為刻面描述子，通常，刻面描述被限定不超過7或8個刻面。作為一個簡單的在構件分類中使用刻面的例子，考慮使用下列構件描述子的模式：｛function，objecttype，systemtyPe｝刻面描述子中的每個刻面可含有一個或多個值，這些值一般是描述性關鍵詞，例如，如果功能(function)是某構件的刻面，賦給此刻面的典型值可能是：function=(copy，from)or(copy，replace，all)多個刻面值的使用使得原函數copy能夠被更完全地精化。關鍵詞(值)被賦給復用庫中的每個構件的刻面集，當軟件工程師在設計中希望查詢構件庫以發現可能的構件時，規定一列值，然后到庫中尋找匹配項。可使用自動工具以完成同義詞詞典功能，這使得查找不僅包括軟件工程師給出的關鍵詞，還包括這些關鍵詞的技術同義詞。刻面分類模式給領域工程師在刻劃構件的復雜描述子時更大的靈活性，因為可以很容易地加入新的刻面值，因此，刻面分類模式比枚舉分類方法易于擴展和進行適應性修改。屬性—值分類(Attribute－ValueClassification)。為領域中的所有構件定義一組屬性，然后值被以和刻面分類方法非常相似的方式賦給這些屬性，事實上，屬性-值分類方法和刻面分類方法是類似的，除了下面幾點不同：(1)對可使用的屬性數量沒有限制，(2)屬性沒有優先級，(3)不使用同義詞詞典功能。基于對上面分類技術的實驗研究，Frank和Pole指出沒有明顯“最好”的技術和“沒有某種方法比別的方法在查找效果上更適度…”。對復用庫有效的分類模式的開發仍有許多工作要做。5.2、構件復用環境軟件構件復用必須有環境的支撐，環境應包含如下元素：*用于存儲構件和對檢索構件必需的分類信息的構件庫。*提供對構件庫訪問的庫管理系統。*允許客戶應用從構件庫服務器中檢索構件和服務的軟件構件檢索系統(如，對象請求代理)。*將復用的構件集成到新設計或實現中的CASE工具。每一個功能在復用庫的范圍內交互或者被包含在復用庫中。復用庫是一個更大型CASE倉庫的一個元素，并且為一系列可復用軟件制品(例如，規約、設計、代碼、測試用例、用戶指南)的存儲提供設施。復用庫包含一個數據庫以及查詢數據庫和構件檢索所必需的工具，構件分類模式是構件庫查詢的基礎。查詢通常用前面描述的3C模型中的語境來刻劃，如果某初始查詢產生大量的候選構件，則查詢被求精以減少候選對象。然后，概念和內容信息被抽取出來(在找到候選構件集后)以輔助開發者選擇合適的構件。6、總結過去幾年，大量來自產業實例研究的證據表明從積極的軟件復用可獲得實質性的商業收益，產品質量、開發生產率、以及整體成本都將得到改善。質量。理想情況下，為了復用而開發的軟件構件已被驗證是正確的且不含有錯誤。在現實中，形式化驗證并不能定期地執行，錯誤可能、也確實存在。然而，隨著每一次復用，錯誤被發現和消除，構件的質量也隨之改善。隨時間的推移，構件變成實質上無錯誤的。在HP公司的研究中，Lim報告說：被復用代碼的錯誤率是每KLOC有0.9個錯誤，而新開發代碼的錯誤率是每KLOC有4.1個錯誤。對一個包含60％復用代碼的應用來說，錯誤率是每KLOC有2.0個錯誤——對期望的錯誤率有51％的改善，相對于不使用復用的開發。Henry和Faller的研究指出在質量上有35％的改善。雖然不同的報告得到不同的改善率(位于合理的范圍內)，但是，公正地說，復用對交付的軟件在質量和可靠性方面確實帶來了實質性的收益。生產率。當可復用軟件制品被應用于軟件開發全過程中，對開發一個可交付系統所必需的計劃、模型、文檔、代碼和數據的創建工作將花費較少的時間，導致的結果是用較少的投入給客戶提供了相同級別的功能，因此生產率得到了改善。雖然，對生產率改善百分率的報告是眾所周知難于解釋的，①但是，似乎30％到50％的復用可以產生25％到40％的生產率改善。成本(COST)。對復用帶來的凈成本節省估算如下：估算出項目如果是從頭開始開發所需的成本C，然后減去和復用關聯的成本C與被交付的軟件的實際成本Cs之和。Cs可以用估算技術的一個或多個來確定，和復用關聯的成本Cs包括：*領域分析和建模。*領域體系結構開發。*為促進復用所增加的文檔量。*可復用軟件制品的維護和增強。*對從外部獲取的構件的版稅和許可證(licenses)費。*可復用構件庫的創建或者獲得以及操作。*對設計和構造復用的人員的培訓。雖然和領域分析與復用庫操作相關聯的成本可能是實質性的，但是它們由很多項目分擔。上面提到的很多其他成本所強調的問題實際上是一個好的軟件工程習慣的一部分，不管是否優先考慮復用。第4章軟件概要設計學習本章，我們要考慮以下幾個問題：軟件概要設計指的是什么?軟件概要設計要做的事情是什么?用什么來評價軟件設計的技術質量?軟件結構優化的準則是什么?如何進行軟件概要設計?以上問題就是本章所要討論的內容。一、軟件概要設計指的是什么?我們知道，軟件設計是把一個軟件需求轉換為軟件表示的過程，而概要設計(又稱結構設計)就是軟件設計最初形成的一個表示(這里的表示是一個名詞)，它描述了軟件的總的體系結構。簡單地說軟件概要設計就是設計出軟件的總體結構框架。而后對結構的進一步細化的設計就是軟件的詳細設計或過程設計。本章所學內容主要就是軟件的概要設計內容。二、軟件概要設計的基本任務軟件概要設計階段要做的事情是什么呢?總的來看有四個方面:它們是1、設計軟件系統結構(軟件結構)2、數據結構及數據庫設計3、編寫概要設計文檔4、評審在需求分析階段，已經把系統分解成層次結構，而在概要設計階段，需要進一步分解，劃分為模塊以及模塊的層次結構。劃分的具體過程是：(1)采用某種設計方法，將一個復雜的系統按功能劃分成模塊。(2)確定每個模塊的功能。(3)確定模塊之間的調用關系。(4)確定模塊之間的接口，即模塊之間傳遞的信息。(5)評價模塊結構的質量。對于大型數據處理的軟件系統，還要對數據結構及數據庫進行設計。在概要設計階段，還要編寫概要設計文檔，我們初學者有一個不是很好的做法，就是在編程序時，往往不注意文檔的編寫，導致以后軟件修改和升級很不方便，用戶使用時也得不到幫助。所以應該在軟件設計的每個階段編寫相應文檔，在概要設計階段，主要有以下文檔需要編寫：(1)概要設計說明書。(2)數據庫設計說明書。(3)用戶手冊，(4)修訂測試計劃。最后一個任務就是評審，在概要設計中，對設計部分是否完整地實現了需求中規定的功能、性能等要求，設計方案的可行性，關鍵的處理及內外部接口定義正確性、有效性，各部分之間的一致性等都要進行評審，以免在以后的設計中發現大的問題而返工。以上就是軟件概要設計的四個基本任務，總結一下用八個字表示：兩類結構文檔評審。(兩類結構就是指軟件結構和數據結構及數據庫設計)在了解了軟件概要設計的基本任務之后，我們來看看軟件設計的基本原理，也就是用于衡量軟件設計的技術質量的一些標準。三、軟件設計的基本原理1、模塊化模塊就是指在程序中的數據說明、可執行語句等程序對象的集合,或者是單獨命名和編址的元素。如高級語言中的過程，函數、子程序等。每個模塊可以完成一個特定的子功能，各個模塊可以按一定方法組裝起來成為一個整體。從而實現整個系統的功能。來源：模塊化就是指解決一個復雜問題時自頂向下逐層把軟件系統劃分成若干模塊的過程。為了解決復雜的問題，在軟件設計中就必須把整個問題進行分解來降低復雜性，這樣就可以減少開發工作量并降低開發成本和提高軟件生產率。但是劃分模塊并不是越多越好，因為這會增加模塊之間接口的工作量。所以劃分模塊的層次和數量應該避免過多或過少。2、抽象抽象這個詞本身也比較抽象,(老師要小明用抽象和具體造一個句子，可是他不懂，就問媽媽，什么是抽象，什么是具體?媽媽告訴他：抽象就是看不見摸不著的，具體就是看得見摸得著的。小明懂了，很快造好了一個句子，是這樣的：今天我很早起床，看見具體的媽媽在炒具體的菜，我打開窗戶，抽象的新鮮空氣呼地一下跑進來，真舒服啊。)呵呵，事實上，抽象并不是這么簡單的意思，它是一種思維工具，就是把事物本質的共同特性抽出來而不考慮其他細節，比如說我們可以把把男人女人老人小孩的共同本質特性抽出來之后形成一個概念"人"，這個概念就是抽象的結果。在軟件工程中就是這樣，在每個階段中，抽象的層次逐步降低，在軟件結構設計中的模塊分層也是由抽象到具體的分析和構造出來的。比如上一層的模塊所進行的加工是一個抽象的操作"銷售統計"，分解到最后一層，就可能是具體"打印報表"的操作了。3、信息隱蔽信息隱蔽的意思就是指，在設計和確定模塊時，使得一個模塊內包含的信息(過程或數據)，對于不需要這些信息的其他模塊來說是不能訪問的。舉個例子吧，假設我是程序中的一個模塊，電話機是另一個模塊，我在使用電話機時，對電話機的控制是通過幾個按鍵來確定的，輸入的數據是我的語音，輸出的數據是對方的語音，而這些輸入、輸出的數據變換以及控制在電話機內部是怎么實現的我不需要知道，同時也不能加以直接控制，這樣，如果電話機壞了，修復或更換后對我的使用是沒有任何影響的。所以說，電話機這個模塊的信息隱蔽是十分完善的。在軟件設計中，模塊的劃分也要采取措施使它實現信息隱蔽。4、模塊獨立性模塊獨立性是指每個模塊只完成系統要求的獨立的子功能，并且與其他模塊的聯系最少且接口簡單。這個概念就是上面說的三個基本原理的直接產物，在概要設計過程中，就是要求設計出具有良好模塊獨立性的軟件結構。那么如何來衡量軟件的模塊獨立性呢?這里有兩個定性的度量標準。(1)耦合性：就是指模塊之間的聯系緊密程度。模塊之間聯系越緊密，其耦合性越強，獨立性就越差。模塊的耦合性從低到高可分為以下幾種類型：(假設某人為一模塊)無直接耦合(比如陌生人之間的聯系)數據耦合(比如去售貨員與顧客之間的聯系)標記耦合(比如兩個人下棋)控制耦合(領導和下屬之間的聯系)公共耦合(比如圖書館的所有借書者之間的聯系)內容耦合(比如小兩口之間的聯系)在軟件設計中，提高模塊的獨立性，建立模塊間盡可能松散的系統，是模塊化設計的目標。為了降低模塊間的耦合度，可以采取以下措施：(1)在耦合方式上降低模塊間接口的復雜性。(2)在傳遞信息類型上盡量采用數據耦合，避免使用控制耦合，慎用或有控制地使用公共耦合。在實踐中要根據實際情況綜合考慮。2、內聚性內聚性是指模塊內部各個元素彼此結合的緊密程度。根據內聚性的從低到高可分為以下六種類型：偶然內聚：指一個模塊內的各處理元素之間沒有任何聯系。(公共汽車內的人群)邏輯內聚：指模塊內執行幾個邏輯上相似的功能，通過參數確定該模塊完成哪一個功能。(警察局里的警察)時間內聚：把需要同時執行的動作組合在一起形成的模塊為時間內聚模塊。(交響樂團的演奏員)通信內聚：指模塊內所有處理元素都在同一個數據結構上的操作。或者指各處理使用相同的輸入數據或者產生相同的輸出數據。(建筑工地上的工人)順序內聚：指一個模塊中各個處理元素都密切相關于同一功能且必須順序執行，前一功能的元素的輸出就是下一功能元素的輸入。(我們可以想像紡織廠中從紡紗到織布的各個操作形成的一個模塊，就是一種順序內聚)功能內聚：這是最強的內聚，指模塊內所有元素共同完成一個功能，缺一不可，模塊已不可再分。(就如兩個人演獅子舞，要完成獅子形象的再現，兩個人缺一不可.)耦合性與內聚性是模塊獨立性的兩個定性標準，將軟件系統劃分模塊時，盡量做到高內聚，低耦合，提高模塊的獨立性。在內聚性與耦合性發生矛盾的時候，最好優先考慮耦合性，也就是先保證耦合性低一些。四、軟件結構的優化準則首先應學會用圖形表示軟件結構，軟件結構圖反映了整個系統的功能實現，即將來編好程序中的控制層次體系。軟件結構往往用樹狀或網狀結構的圖形來表示。請大家對照課本的解釋來看軟件結構圖包括哪些內容。我們已經知道了軟件概要設計的主要任務就是軟件結構的設計，為了提高設計的質量，可以根據下面的設計優化準則進行優化：在這些準則中，都是針對模塊及模塊間關系來提出的。1、模塊的劃分：要做到高內聚，低耦合，保持相對獨立性。2、模塊的控制：模塊的作用范圍要在他的控制范圍內，判定所在的模塊應與受其影響的模塊在層次上盡量靠近)3、形成的結構;軟件結構的深度、寬度、扇出、扇入要適當4、模塊的大小:要適中。5、模塊的接口：模塊的接口要簡單、清晰、含義明確，便于理解、易于實現、測試與維護)。五、概要設計的設計方法。(一)面向數據流的設計方法(這是需要我們熟練掌握的方法)面向數據流的設計方法是以需求階段產生的數據流圖為基礎，按一定的步驟映射成軟件結構，因此又稱為結構化設計(StructuredDesignSD)。這是目前使用最廣泛的軟件設計方法之一，應該熟練掌握它。1、首先要研究數據流圖(DFD)的類型，無論何種軟件系統，DFD一般都可分為變換型和事務型兩類。(課本第51頁)先來看變換型數據流圖，顧名思義，變換就是把輸入的數據處理后變成另外的數據輸出，所以變換型數據的工作過程就是三步：取得數據、變換數據和輸出數據。在圖4-6中，可以看到兩股數據流經過交換中心變成一股數據流進行輸出。虛線為標出的流界。再來看事務型數據流圖，所謂事務也是一個處理，但不是數據變換，而是將輸入數據流分離成許多發散的數據流，形成許多加工路徑，并根據值選擇其中一個路徑來執行。舉個例子，好比有一個郵件分發中心，把收進的郵件根據其發送地址進行分流，有的用飛機郵送，有的用汽車來運輸等等。在大型軟件系統中的DFD數據流圖中，這兩種類型特征都有可能存在。2、SD方法設計過程1)精化DFD。2)確定DFD類型并進行相應的映射。3)分解上層模塊，設計中下層模塊結構4)根據優化準則對軟件結構求精。5)描述模塊功能、接口及全局數據結構6)復查，如果有錯則轉向2)修改完善，否則進入詳細設計。下面我們通過例