《軟件工程-理論、方法與實踐》課件第6章

第6章軟件設計6.1軟件設計過程6.2軟件設計原則6.3體系結構設計6.4控制模型6.5模塊分解6.6體系結構設計案例本章小結習題

6.1軟件設計過程

軟件設計活動主要涉及體系結構設計、數(shù)據(jù)設計、接口設計和組件(過程)設計等內容，是將需求分析模型轉換為設計模型的過程，如圖6.1所示。圖6.1軟件設計過程的主要活動

6.2軟件設計原則

軟件設計活動應遵循一定的原則以提高軟件實現(xiàn)的質量。軟件設計應使軟件實體有明顯的層次結構，以利于軟件元素間的控制；軟件應是模塊化的且模塊具有獨立性；軟件實體邊界要清晰，具有良好的接口；設計規(guī)格說明也要清晰、簡潔、完整、無二義性。6.2.1模塊化和信息隱蔽

一個軟件系統(tǒng)通常是一個能完成多種需求的復雜系統(tǒng)，例如一個圖書管理系統(tǒng)，需要能處理圖書的分類登記、定購、借閱等多種服務，而僅用一個模塊來實現(xiàn)復雜系統(tǒng)是不現(xiàn)實的。經驗表明人類求解問題過程的復雜性和工作量與單個問題的規(guī)模密切相關。設待求解的問題為X，則C(X)?和E(X)?分別為X相應的復雜性和解決問題所需要的工作量。

設對于問題P1、P2，若有C(P1)?>?C(P2)，則有E(P1)?>E(P2)。而另一方面，人類實踐表明：

C(P1?+?P2)?>?C(P1)?+?C(P2)

因此

E(P1?+?P2)?>?E(P1)?+?E(P2)這說明將一個復雜的大系統(tǒng)分解成若干個相對簡單的子系統(tǒng)(Subsystem)稱為大系統(tǒng)模塊化，使得求解問題的復雜性和工作量比一個大系統(tǒng)要小，求解更為容易。但模塊的分解并非越多越好，模塊之間存在著交互接口，當模塊過多時，將會增加接口的代價，圖6.2說明了這樣的問題。從圖中可以看出，對于給定的問題，分解的粒度有一個最小成本區(qū)M，模塊分解得過多或過少均會帶來較大的成本開銷。圖6.2模塊與軟件消耗一個復雜的系統(tǒng)可以按層次分解為子系統(tǒng)(Subsystem)，組件/服務(Components/Services)，類(Class)和函數(shù)(function)，它們構成了不同層次的系統(tǒng)模塊，如圖6.3所示。圖6.3復雜系統(tǒng)的構成6.2.2內聚和耦合

內聚(Cohesion)是子系統(tǒng)內部的相關程度。當子系統(tǒng)中彼此相關的多個對象執(zhí)行類似的任務時，則認為該子系統(tǒng)是高內聚的；反之，當子系統(tǒng)內的多個對象彼此不相關時，則認為系統(tǒng)是低內聚的。高內聚的方法完成且僅完成一個功能，這使得子系統(tǒng)易于理解和維護。例如方法changeItem()要完成書目的讀取、增加、修改和刪除等若干方法的功能，則需具有較多的代碼行和較復雜的控制邏輯以便完成多個功能，這會為程序的可理解性帶來影響，并且由于功能較多將會有較多的其他模塊與之發(fā)生關聯(lián)，給后期的維護帶來困難。偶然內聚是指一個模塊內容為了節(jié)約空間，將并無多少邏輯關聯(lián)的代碼和數(shù)據(jù)組合在一起，常見的偶然內聚發(fā)生是當程序員寫完一個程序后發(fā)現(xiàn)有一組語句多處出現(xiàn)，于是為節(jié)省內存便將這組語句單獨組成一個模塊；邏輯內聚是指一個模塊完成的多個任務邏輯上相關。例如，一個模塊完成所有類型的數(shù)據(jù)輸出，這類模塊調用時需要傳送控制信息，以便控制不同任務的處理；如果一個模塊包含的多個任務必須在同一時間段內執(zhí)行，則稱之為時間內聚，例如一個系統(tǒng)的初始化模塊；過程內聚則是指模塊內成分彼此邏輯相關，并且必須按特定的次序執(zhí)行；模塊中各成分引用共同的輸入數(shù)據(jù)或產生相同的輸出數(shù)據(jù)則稱為通信內聚，這意味著一個模塊可能包含多個功能，但卻是對相同的數(shù)據(jù)進行操作，見圖6.4；如果一個模塊內的各處理成分均與同一功能相關，且這些處理必須順序執(zhí)行，即模塊中某個成分的輸出是另一成分的輸入則稱順序內聚，見圖6.5；如果模塊完成單個功能且不易再分解，則稱功能內聚，如求平方根、計算利息等。圖6.4通信內聚圖6.5順序內聚偶然內聚、邏輯內聚、時間內聚被認為是低級內聚，設計時應盡量避免。過程內聚、通信內聚是中級內聚，而順序內聚和功能內聚則是高級內聚。設計時應提高內聚度從而獲得較好的模塊獨立性。如高內聚的類表示且僅表示一種類型的對象，例如在一個大學人事管理系統(tǒng)中使用Professor類則比用Employee類更好，因為Employee類涵蓋的范圍更大。耦合(Coupling)表示兩個子系統(tǒng)(或類)之間的關聯(lián)程度，當一個子系統(tǒng)(或類)發(fā)生變化時對另一個子系統(tǒng)(或類)的影響很小，則稱它們是松散耦合的；反之，如果變化的影響很大時，則稱它們是緊密耦合的。耦合的強弱取決于模塊間接口的復雜性、引用模塊的位置和數(shù)據(jù)的傳送方式等。設計時應盡量使模塊間的耦合度小，模塊間的耦合度直接影響系統(tǒng)的可理解性、可測試性、可靠性和可維護性。耦合也可分為七級，從低至高為：非直接耦合(Nondirectcoupling)、數(shù)據(jù)耦合(Datacoupling)、標記耦合(Stampcoupling)、控制耦合(Controlcoupling)、外部耦合(Externalcoupling)、公共耦合(Commoncoupling)、內容耦合(Contentcoupling)。耦合度應越低越好。

若兩模塊間彼此無任何交互，則稱之為非直接耦合；若兩模塊間僅通過參數(shù)交換信息則稱為數(shù)據(jù)耦合，一般系統(tǒng)中均需要存在這類耦合；如果模塊間傳送的參數(shù)包含著復合數(shù)據(jù)結構，則為標記耦合，例如含有若干數(shù)據(jù)項的數(shù)據(jù)記錄；若傳遞的參數(shù)中含有控制信息則上升為控制耦合，如一個標志信息用于控制模塊內部邏輯(見圖6.6)；當若干模塊與同一個外部環(huán)境關聯(lián)，則模塊間存在著外部耦合。如I/O處理使所有I/O模塊與特定的設備、格式和通信協(xié)議相關聯(lián)；公共耦合則是指模塊間存在著全局變量、公共數(shù)據(jù)區(qū)或可共享的文件等；而內容耦合是指模塊間存在著一個模塊直接轉入另一模塊的內部或一個模塊直接使用另一模塊的數(shù)據(jù)或控制信息，見圖6.7。圖6.6控制耦合圖6.7內容耦合6.2.3抽象和求精

“抽象(Abstract)是人類處理復雜問題的基本方法之一”(Booch)。抽象是對問題的簡化和概括，它忽略了問題的某些細節(jié)，有助于把握問題的本質。抽象是分層次的，在軟件系統(tǒng)中，高層次的抽象是概念性的，例如用例模型。較低層次的抽象則是具體解決方案和細節(jié)，例如類的定義。抽象是自底向上的，是從細節(jié)到概要的過程。求精(Refine)是抽象的逆過程，是對問題自頂向下逐步分解、細化至細節(jié)的過程。抽象和細化不僅是軟件設計反復運用的原則，也貫穿于軟件過程活動中。圖6.8示意了對同一問題的兩個不同抽象級別的描述，可以看出算法2是算法1的細化，而算法1是算法2的抽象。圖6.8對同一問題的兩個不同抽象級別的描述6.2.4復用

所謂復用(Reuse)就是利用某些已開發(fā)的、對建立新系統(tǒng)有用的軟件元素來生成新的軟件系統(tǒng)。復用的好處在于提高生產效率，提高軟件質量，改善軟件系統(tǒng)的可維護性。目前軟件技術的發(fā)展和軟件機構項目經驗的積累，已具有大量商品化或非商品化的成熟軟件組件，因此一個新的系統(tǒng)的構成，可以充分復用現(xiàn)成的軟件組件，僅需部分編碼。成熟的組件具有較小的風險，且可以加速開發(fā)工作和降低開發(fā)成本及維護代價。

6.3體系結構設計

6.3.1什么是體系結構

軟件體系結構的概念早在20世紀80年代就已經提出。真正引起關注和重視是在90年代，有效的軟件體系結構及明確的描述和設計，已經成為軟件工程領域中重要的主題。許多研究人員基于自己的經驗從不同角度、不同側面對體系結構進行了刻畫。軟件體系結構涉及多方面的內容：軟件的組成組件及系統(tǒng)構架；軟件各組件的選擇，各組件之間的相互作用，軟件組件的進一步分解以及指導軟件分解過程的總體模式；系統(tǒng)的功能、性能、設計以及從多種方案中進行選樣的決策。

軟件體系結構關注的是系統(tǒng)結構及其組成組件，軟件體系結構設計開始于系統(tǒng)的早期設計階段。體系結構模型主要描述以下屬性：系統(tǒng)的組件，包括功能組件和數(shù)據(jù)組件；系統(tǒng)組件間的連接，包括數(shù)據(jù)流和控制流；組件和連接的約束，包括組件間的通信協(xié)議，組件間的同步等；以及用組件和連接表示的系統(tǒng)整體結構的拓撲關系。因而組件和連接器是軟件體系結構的兩大構成部分。最簡單的連接器可表現(xiàn)為組件之間的直接連接，如功能調用。當情況復雜時，則有專門的連接器，正如連接硬件設備的特定連接裝置，軟部件之間也需要連接器，如進程間通信所構成的連接器。連接器的通用表示如圖6.9所示。圖6.9連接器的通用表示6.3.2體系結構設計策略

一個子系統(tǒng)的識別和設計過程實際是將一個系統(tǒng)分解為大粒度組件的過程，通常可以用塊圖來描述，也可用UML的包圖表示。圖6.10構成了一個層次結構的體系結構。圖6.10OSI體系結構基于已有的知識和經驗，體系結構的設計決策主要應考慮以下一些問題：

(1)對于被設計的系統(tǒng)來說，是否存在通用的體系結構模板？

(2)所設計的系統(tǒng)是否要分布在不同的處理器上？

(3)對于系統(tǒng)來說什么是適合的體系結構風格？

(4)建立系統(tǒng)結構的基本方法是什么？

(5)系統(tǒng)的結構部件如何進一步被分解成模塊？

(6)使用何種策略控制系統(tǒng)組件的操作？

(7)如何評價體系結構設計？

(8)系統(tǒng)的體系結構如何被文檔化？使用軟件體系結構的風格和模式對軟件開發(fā)具有重要的應用價值和經濟效益：

(1)它可以便于設計開發(fā)者之間相互交流和理解。只要系統(tǒng)是使用某種風格或模式的規(guī)范方法來組織，則別的設計者就很容易理解系統(tǒng)的體系結構。譬如某人把系統(tǒng)描述為“管道-過濾器”模式，則他不必給出細節(jié)，人們立刻就明白系統(tǒng)是如何組織起來的，并在腦海中清晰地得到此系統(tǒng)的圖像。

(2)使用軟件體系結構的風格或模式促進了設計的復用。許多經過實踐證明的軟件結構可以用來解決許多相似類型的新問題。這給新軟件的開發(fā)帶來了便利和質量保證。

(3)使用軟件體系結構的風格和模式也促進了代碼復用。對于體系結構風格中的不變部分，不同的系統(tǒng)可以共同應用同一段實現(xiàn)代碼，從而提高了該段代碼的應用價值。

(4)使用軟件體系結構的標準風格和模式有利于支持互操作性，例如像CORBA這種面向對象的結構和基于事件機制的集成模式。6.3.3管道-過濾器結構

從整個系統(tǒng)的輸入和輸出關系看，各過濾器通過對其輸入進行局部的獨立處理變換，就可以產生部分的計算結果。過濾器的活動可以通過以下方法激活：

(1)后續(xù)的部件從過濾器中取出數(shù)據(jù)。

(2)前續(xù)的部件向過濾器推入新輸入數(shù)據(jù)。

(3)過濾器處于活躍狀態(tài)，不斷地從前續(xù)的部件取出并向后續(xù)的部件推入數(shù)據(jù)。在UNIX中，用戶可以定義和啟動多個任務進程來充當過濾器，它們在操作系統(tǒng)的控制下并行地工作，等待輸入數(shù)據(jù)的到來，并啟動工作，經過一步步過濾器的計算，最終得到處理結果。

管道-過濾器結構在信號處理、分布式計算等處理中獲得了廣泛使用。圖6.11是管道-過濾器的一個示例。圖6.11管道-過濾器示例管道-過濾器具有如下一些特性：

(1)過濾器是獨立運行的部件。也就是說，除了輸入和輸出外，各過濾器不受任何其他過濾器運行的影響。在設計實現(xiàn)上，非鄰近的過濾器之間不共享任何狀態(tài)，甚至對于多次加工而言，過濾器自身也是無狀態(tài)的。換言之，每次加工之后，過濾器都會回到統(tǒng)一的原始等待狀態(tài)。

(2)過濾器的獨立性還在于它對其處理的上游和下游連接的過濾器的“無知”。它的設計和使用不對與其相連的任何過濾器施加限制，唯一關心的是其輸入的形式、加工處理的邏輯、產生輸出的形式。

(3)過濾器的獨立性，還表現(xiàn)在整個結果的正確性不依賴于各個過濾器運行的先后次序。盡管其最終輸出形式的獲得需要經過特定的加工，并符合加工的順序要求，但在系統(tǒng)工作時，各過濾器只在具備輸入數(shù)據(jù)后獨立地完成自己的計算。6.3.4分層體系結構

一個分層系統(tǒng)采用層次化的組織方式構建，系統(tǒng)中的每一層都要承擔兩個角色。首先，它為結構中的上層提供服務；其次，它作為結構中下層的客戶，調用下層提供的功能函數(shù)。

一個概念上的分層模型如圖6.12所示。圖6.12分層結構示例圖6.12中包含三個層次，數(shù)據(jù)訪問層控制對底層數(shù)據(jù)庫的訪問；業(yè)務邏輯層實現(xiàn)系統(tǒng)的業(yè)務邏輯，為核心層；接口層提供與用戶和其他系統(tǒng)的交互。這三個層次內部可以包含很多的功能組件，每一層都是一個由組件構成的虛擬機。各虛擬機之間通過系統(tǒng)設計的協(xié)議(可以是標準或完全私人的協(xié)議)通信，通信方式往往采用過程調用予以體現(xiàn)。6.3.5倉庫系統(tǒng)結構

一個系統(tǒng)通常會被分解成若干個子系統(tǒng)，若一個系統(tǒng)中存在著一個共享的數(shù)據(jù)庫，所有的其他子系統(tǒng)基于這個數(shù)據(jù)處理子系統(tǒng)交換數(shù)據(jù)，這樣的體系結構模型稱之為倉庫(Repository)系統(tǒng)模型。

倉庫模型中含兩類子系統(tǒng)，中心數(shù)據(jù)倉庫和對數(shù)據(jù)進行存儲、檢索和更新的子系統(tǒng)。因此這種模型適用于由一個系統(tǒng)生成數(shù)據(jù)而其他子系統(tǒng)使用數(shù)據(jù)的場合，例如圖6.13所示的編譯系統(tǒng)。圖6.13編譯系統(tǒng)體系結構6.3.6客戶/服務器模式

客戶、服務器體系結構是一種適用于分布式環(huán)境下的系統(tǒng)結構，系統(tǒng)中包括兩類子系統(tǒng)：服務器子系統(tǒng)和客戶子系統(tǒng)，系統(tǒng)將服務的集合交由服務器子系統(tǒng)來提供，客戶子系統(tǒng)通過訪問服務器子系統(tǒng)請求和使用服務，一個系統(tǒng)可以由一組服務器子系統(tǒng)和一組客戶子系統(tǒng)組成?？蛻?服務器模型見圖6.14。圖6.14客戶/服務器模型另一種則是瘦客戶機模型，瘦客戶機模型通常由服務器方承擔所有的業(yè)務處理邏輯，客戶機子系統(tǒng)僅處理與系統(tǒng)用戶之間的交互，當業(yè)務邏輯更改，客戶方無需修改。典型的瘦客戶機模型為基于Internet的Web應用系統(tǒng)。Web應用系統(tǒng)本質上是一種多層的C/S體系結構，如圖6.15所示圖6.15三層B/S結構6.3.7MVC模式

圖6.16顯示了MVC結構中不同子系統(tǒng)之間的關系，控制器收集來自用戶的輸入，控制用戶界面的數(shù)據(jù)顯示，并更新模型對象的狀態(tài)；視圖顯示模型的數(shù)據(jù)，當模型發(fā)生變化時得到通知進行更新；模型是應用程序的主體，表示業(yè)務數(shù)據(jù)或業(yè)務邏輯。圖6.16MVC體系結構

6.4控制模型

6.4.1集中式控制

在集中式控制方式下，一個子系統(tǒng)承擔著系統(tǒng)控制器的角色，可以控制其他子系統(tǒng)的啟、停。集中式控制模型也分為兩類：Call-return模型和管理器(Manager)模型。

Call-return模型是傳統(tǒng)的自頂而下的結構化程序常見的模型，例如C語言、Pascal、Ada等，通過子程序調用完成相應的程序功能。這種控制模型通常用于順序處理的系統(tǒng)，見圖6.17。圖6.17Call-return模型在調用層次上，控制從較高層次被傳送給較低層次的子程序，子程序完成執(zhí)行后，控制會返回到調用點?？刂颇Ｐ鸵部杀挥糜谀K級的函數(shù)和對象的控制邏輯。

管理器模型通常應用于并發(fā)的系統(tǒng)。一個子系統(tǒng)被設計成為系統(tǒng)的管理者，可以控制、協(xié)調其他的子系統(tǒng)或進程。這些子系統(tǒng)或進程可以并發(fā)執(zhí)行。這種模型常被用于實時系統(tǒng)控制。圖6.18是一個實時系統(tǒng)控制模型。圖6.18管理器模型6.4.2事件驅動的控制

在事件驅動的控制模型下，控制的轉移交付由外部產生的事件所觸發(fā)，比如來自系統(tǒng)外部設備發(fā)出的請求或某一個進程的請求等。事件驅動的控制一般也可分為兩類：廣播模型和中斷驅動的模型。

在廣播模型中，事件發(fā)生后會被廣播給系統(tǒng)中的所有子系統(tǒng)，預先注冊的對該事件有興趣的子系統(tǒng)響應該事件，從而實現(xiàn)控制的轉移。圖6.19是一個廣播模型示意。圖6.19事件驅動的控制中斷驅動的模型通常用在實時系統(tǒng)中，在系統(tǒng)中為外部事件設置了中斷處理程序，并將程序指針存放在中斷向量表中，一旦中斷事件發(fā)生，系統(tǒng)會自動轉向中斷向量表中指定的處理程序。廣播模型適合網(wǎng)絡環(huán)境下子系統(tǒng)的集成。在廣播模型下，存在一個事件(或消息)處理器(Handler)，它維護著一張注冊表，以存放對事件感興趣的子系統(tǒng)。事件(或消息)處理器檢測事件，檢查注冊表并傳遞事件給已注冊的子系統(tǒng)。值得注意的是，這種模型下控制策略并不嵌入在事件(或消息)處理器中。由子系統(tǒng)決定需要處理哪一個事件，事件(或消息)處理器只是確保把事件發(fā)送給它們。如在Windows系統(tǒng)中，有專門的程序來偵聽鼠標、鍵盤等來自用戶接口的事件，并將它們轉換成消息傳遞出去。廣播模型的優(yōu)點是擴展性較好，如果要增加一個響應事件的子系統(tǒng)，只需在注冊表中注冊該子系統(tǒng)。另外，一個子系統(tǒng)可以通過事件激活其他的子系統(tǒng)卻不需要知道它們的名字和位置，因此適用于在分布式環(huán)境，如ORB(ObjectRequestBrokers)。但這種模式也存在不定，即子系統(tǒng)無法預知事件何時發(fā)生，并且產生事件的子系統(tǒng)也無法知道響應該事件的是哪一個子系統(tǒng)。在多個響應子系統(tǒng)間還可能存在沖突，因此系統(tǒng)還需考慮如何解決響應沖突的問題。在實時系統(tǒng)中通常需要對外部產生的事件有著快速的響應，例如煙霧傳感器檢測出的事件、雷達監(jiān)測到的障礙事件等。應對這類事件，則中斷驅動的控制模型較為理想。中斷處理器會中斷當前的進程將控制轉交給系統(tǒng)中斷向量表中所指的中斷處理進程。

中斷處理模型的優(yōu)點是對事件的響應快速及時，缺點則是系統(tǒng)較難驗證，因為在系統(tǒng)測試過程中，中斷環(huán)境幾乎難以復制，且中斷事件往往取決于硬件設備，中斷事件的觸發(fā)較為復雜。

6.5模塊分解

面向對象的分解是將子系統(tǒng)分解成對象或類的協(xié)作，將系統(tǒng)職責分配給對象，涉及對象類間的關系及其屬性和操作的指定，通常用類圖來描述。

圖6.20是將一個處理客戶支付的子系統(tǒng)分解成由四個對象類構成的對象模型。圖6.20面向對象的分解圖6.20示意，支付子系統(tǒng)由存儲客戶信息的Customer類、存儲支付信息的Payment類、存儲收款信息的Receipt類和處理支付的Invoice類構成?？梢钥闯鯟ustomer、Payment和Receipt為實體類，而Invoice為一個控制類，設計將支付信息的發(fā)布、提醒付款、處理付款和開出收據(jù)等