軟件?程之軟件概要設計

在完成對軟件系統(tǒng)的需求分析之后，接下來需要進?的是軟件系統(tǒng)的概要設計。?般說來，對于較?規(guī)模的軟件項?，軟件設計往往被分成兩個階段進?。?先是前期概要設計，?于確定軟件系統(tǒng)的基本框架；然后是在概要設計基礎上的后期詳細設計，?于確定軟件系統(tǒng)的內部實現(xiàn)細節(jié)。概要設計也稱總體設計，其基本?標是能夠針對軟件需求分析中提出的?系列軟件問題，概要地回答問題如何解決。例如，軟件系統(tǒng)將采?什么樣的體系構架、需要創(chuàng)建哪些功能模塊、模塊之間的關系如何、數(shù)據(jù)結構如何？軟件系統(tǒng)需要什么樣的?絡環(huán)境提供?持、需要采?什么類型的后臺數(shù)據(jù)庫等。應該說，軟件概要設計是軟件開發(fā)過程中?個?常重要的階段?？梢钥隙?，如果軟件系統(tǒng)沒有經(jīng)過認真細致的概要設計，就直接考慮它的算法或直接編寫源程序，這個系統(tǒng)的質量就很難保證。許多軟件就是因為結構上的問題，使得它經(jīng)常發(fā)?故障，?且很難維護。

?、概要設計過程和任務

1.設計過程

概要設計基本過程如5-1所?，它主要包括三個??的設計。?先是系統(tǒng)構架設計，?于定義組成系統(tǒng)的?系統(tǒng)，以及對?系統(tǒng)的控制、?系統(tǒng)之間的通信和數(shù)據(jù)環(huán)境等；然后是軟件結構和數(shù)據(jù)結構的設計，?于定義構造?系統(tǒng)的功能模塊、模塊接?、模塊之間的調?與返回關系，以及數(shù)據(jù)結構、數(shù)據(jù)庫結構等。

概要設計要求建?在需求分析基礎之上，軟件需求?檔是軟件概要設計的前提條件。只有這樣，才能使得開發(fā)出來的軟件系統(tǒng)最?限度地滿??戶的應?需要。實際上，概要設計的過程也就是將需求分析之中產(chǎn)?的功能模型、數(shù)據(jù)模型和?為模型等分析結論進?轉換，由此產(chǎn)?設計結論的過程。在從分析向設計的轉換過程中，概要設計能夠產(chǎn)?出有關軟件的系統(tǒng)構架、軟件結構和數(shù)據(jù)結構等設計模型來。這些結論將被寫進概要設計?檔中，作為后期詳細設計的基本依據(jù)，能夠為后?的詳細設計、程序編碼提供技術定位。需要注意的是，概要設計所能夠獲得的還只是有關軟件系統(tǒng)的抽象表達式，需要專?考慮的是軟件系統(tǒng)的基本結構，?于軟件系統(tǒng)的內部實現(xiàn)細節(jié)如何，則被放到以后詳細設計中去解決。例如模塊，概要設計中的模塊只是?個外殼，雖然它有確定的功能邊界，并提供了通信的接?定義，但模塊內部還基本上是空的，諸多具體的功能加?細節(jié)則必須等到詳細設計完成以后才能確定下來。因此，在有關軟件設計的全部?作中，概要設計所提供的并不是最終設計藍圖，?只是?份具有設計價值的具體實施?案與策略，?于把握系統(tǒng)的整體布局。盡管概要設計并不涉及系統(tǒng)內部實現(xiàn)細節(jié)，但它所產(chǎn)?的實施?案與策略將會最終影響軟件實現(xiàn)的成功與否，并影響到今后軟件系統(tǒng)維護的難易程度。

2.設計任務

概要設計階段的任務既包括技術??的，也包括管理??的，具體說來，主要有以下?個??：

（1）制定規(guī)范

具有?定規(guī)模的軟件項?總是需要通過團隊形式實施開發(fā)，例如，組成?個或?個開發(fā)?組來承擔對軟件系統(tǒng)的開發(fā)任務。為了適應團隊式開發(fā)的需要，在進?軟件開發(fā)階段之后，?先應該為軟件開發(fā)團隊制定在設計時應該共同遵守的規(guī)范，以便協(xié)調與規(guī)范團隊內各成員的?作。

概要設計時需要制定的規(guī)范或標準包括：

a.需要采?的管理規(guī)則，例如操作流程、交流?式、?作紀律等。

b.設計?檔的編制標準，包括?檔體系、?檔格式、圖表樣式等。

c.信息編碼形式，硬件、操作系統(tǒng)的接?規(guī)約，命名規(guī)則等。

d.設計?標、設計原則。

（2）系統(tǒng)構架設計

系統(tǒng)構架設計就是根據(jù)系統(tǒng)的需求框架，確定系統(tǒng)的基本結構，以獲得有關系統(tǒng)創(chuàng)建的總體?案。其主要設計內容包括：

a根據(jù)系統(tǒng)業(yè)務需求，將系統(tǒng)分解成諸多具有獨?任務的?系統(tǒng)。

b分析?系統(tǒng)之間的通信，確定?系統(tǒng)的外部接?。

c分析系統(tǒng)的應?特點、技術特點以及項?資?情況，確定系統(tǒng)的硬件環(huán)境、軟件環(huán)境、?絡環(huán)境和數(shù)據(jù)環(huán)境等。

d根據(jù)系統(tǒng)整體邏輯構造與應?需要，對系統(tǒng)進?整體物理部署與優(yōu)化。很顯然，當系統(tǒng)構架被設計完成之后，軟件項?就可按每個具有獨??作特征的?系統(tǒng)為單位進?任務分解了，由此可以將?個?的軟件項?分解成許多?的軟件?項?。

（3）軟件結構設計

軟件結構設計是在系統(tǒng)構架確定以后，對組成系統(tǒng)的各個?系統(tǒng)的結構設計。例如，將系統(tǒng)進?步分解為諸多功能模塊，并考慮如何通過這些模塊來構造軟件。

軟件結構設計主要內容包括：

a.確定構造?系統(tǒng)的模塊元素。

b.根據(jù)軟件需求定義每個模塊的功能。

c.定義模塊接?與設計模塊接?數(shù)據(jù)結構。

d.確定模塊之間的調?與返回關系。

e.評估軟件結構質量，進?結構優(yōu)化

（4）公共數(shù)據(jù)結構設計

概要設計中還需要確定那些將被許多模塊共同使?的公共數(shù)據(jù)的構造。例如，公共變量、數(shù)據(jù)?件以及數(shù)據(jù)庫中數(shù)據(jù)等，可以將這些數(shù)據(jù)看作為系統(tǒng)的公共數(shù)據(jù)環(huán)境。對公共數(shù)據(jù)的設計包括：

a.公共數(shù)據(jù)變量的數(shù)據(jù)結構與作?范圍。

b.輸?、輸出?件的結構。

c.數(shù)據(jù)庫中的表結構、視圖結構以及數(shù)據(jù)完整性等。

（5）安全性設計

系統(tǒng)安全性設計包括：操作權限管理設計、操作?志管理設計、?件與數(shù)據(jù)加密設計以及特定功能的操作校驗設計等。概要設計需要對以上??的問題作出專門的說明，并制定出相應的處理規(guī)則。例如操作權限，假如應?系統(tǒng)需要具有權限分級管理的功能，則概要設計就必須對權限分級管理中所涉及的分級層數(shù)、權限范圍、授權步驟以及?戶賬號存儲?式等，從技術?度作出專門的安排。

（6）故障處理設計

軟件系統(tǒng)?作過程中難免出現(xiàn)故障，概要設計時需要對各種可能出現(xiàn)的來?于軟件、硬件以及?絡通信??的故障作出專門考慮。例如，提供備?設備、設置出錯處理模塊、設置數(shù)據(jù)備份模塊等。

（7）可維護性設計

軟件系統(tǒng)在投?使?以后必將?臨維護，如改正軟件錯誤、擴充軟件功能等。對此，概要設計需要作出專門安排，以?便?后的維護。例如，在軟件中設置?于系統(tǒng)檢測維護的專?模塊；預計今后需要進?功能擴充的模塊，并對這些接?進?專門定義。

（8）編寫?檔

概要設計階段需要編寫的?檔包括：概要設計說明書、數(shù)據(jù)庫設計說明書、?戶操作?冊。此外，還應該制定出有關測試的初步計劃。上述?檔中，概要設計說明書是概要設計階段必須產(chǎn)?的基本?檔，涉及系統(tǒng)?標、系統(tǒng)構架、軟件結構、數(shù)據(jù)結構、運?控制、出錯處理、安全機制等諸多??的設計說明。

（9）概要設計評審

在諸多概要設計任務完成之后，應當組織對概要設計的評審。概要設計評審內容主要包括:

a.需求確認：確認所設計的軟件是否已覆蓋了所有已確定的軟件需求。

b.接?確認：確認該軟件的內部接?與外部接?是否已經(jīng)明確定義。

c.模塊確認：確認所設計的模塊是否滿??內聚、低耦合的要求，模塊的作?范圍是否在其控制范圍之內。

d.風險性：該設計在現(xiàn)有技術條件下和預算范圍內是否能按時實現(xiàn)。

e.實?性：該設計對于需求的解決是否實?。

f.可維護性：該設計是否考慮了今后的維護。

g.質量：該設計是否表現(xiàn)出了良好的質量特征

?、系統(tǒng)構架設計

?型的綜合應?系統(tǒng)?都是由許多?系統(tǒng)組成的。?般說來，這些?系統(tǒng)能夠獨?運?，有??專門的服務任務，并可能需要部署在不同的計算機上?作。應該說，組成系統(tǒng)的?系統(tǒng)具有?定的獨?性，但?系統(tǒng)之間?有著聯(lián)系。例如，有共同的數(shù)據(jù)源，相互之間需要通信，并可能需要協(xié)同?作。系統(tǒng)構架設計的任務就是根據(jù)需求規(guī)格中的需求基本框架，把組成系統(tǒng)的這些?系統(tǒng)、?系統(tǒng)之間的關系、它們之間需要的數(shù)據(jù)通信等確定下來，并把它們?作時所需要的設備環(huán)境、?絡環(huán)境和數(shù)據(jù)環(huán)境等也?同確定下來，由此對系統(tǒng)作出?個合理的、符合應?需要的整體部署。需求分析中的需求框架是基于?戶應?域建?的，概要設計時可以通過需求框架來映射系統(tǒng)構架。例如，可以利?需求分析中的?層數(shù)據(jù)流圖對系統(tǒng)基本?作流程的描述，來映射系統(tǒng)的基本結構，使得需求分析中對系統(tǒng)的邏輯描述，轉換為概要設計中對系統(tǒng)的物理描述。?般情況下，系統(tǒng)構架設計可以按照以下步驟進?。

（1）定義?系統(tǒng)。根據(jù)需求分析中有關系統(tǒng)的業(yè)務劃分情況，將系統(tǒng)分解成諸多具有獨?任務的?系統(tǒng)。

（2）定義?系統(tǒng)外部接?。分析?系統(tǒng)之間的通信與協(xié)作，以獲得對?系統(tǒng)外部接?的定義。

（3）定義系統(tǒng)物理構架。根據(jù)系統(tǒng)的整體邏輯結構、技術特點、應?特點以及系統(tǒng)開發(fā)的資?投?情況等，選擇合適的系統(tǒng)物理構架，包括：硬件設備、軟件環(huán)境、?絡結構和數(shù)據(jù)庫結構，并將?系統(tǒng)按照所選的物理構架進?合理部署與優(yōu)化。下?將介紹?種典型的系統(tǒng)構架。需要注意的是，任何?種結構都會有優(yōu)點與缺點，盡管是?些現(xiàn)在看來已經(jīng)過時的結構也有它存在的現(xiàn)實價值。

1.集中式結構

集中式結構是最傳統(tǒng)的系統(tǒng)構架，系統(tǒng)由?臺計算機主機和多個終端設備組成，其結構如圖5-2所?。集中式結構的特點是系統(tǒng)中的全部軟件資源都被集中安裝在這?臺主機上，包括：操作系統(tǒng)、數(shù)據(jù)庫系統(tǒng)、應?系統(tǒng)和資源?件等。系統(tǒng)的智能處理器也被集中在主機上。?戶則是通過和主機連接的基本?智能的終端設備與系統(tǒng)進?通信。由于所有計算任務都通過主機完成，因此集中式結構對計算機性能有?較?的要求。早期應?中?般使??型以上計算機提供?較強?的主機計算?持，操作系統(tǒng)則?般Unix系統(tǒng)，能夠向外提供多?戶服務。

應該說，集中式結構具有?常好的?作穩(wěn)定性。另外，由于集中式結構是直接通過終端接?實現(xiàn)多?戶通信，因此系統(tǒng)還具有較?的安全保密特性。集中式結構優(yōu)點是?穩(wěn)定性和?安全性。但集中式結構有較苛刻的設備要求，系統(tǒng)建設費?、運?費?都?較?，?且系統(tǒng)靈活性不夠好，系統(tǒng)結構不便于擴充。

2.客戶機/服務器結構

客戶機/服務器結構是?種分布與集中相互結合的結構，系統(tǒng)依靠?絡被分布在許多臺不同的計算機上，但通過其中的服務器計算機提供集中式服務。圖5-3所?的是客戶機/服務器結構的典型應?。這是?個提供視頻信息和圖?信息的多?戶超?本應?系統(tǒng)，系統(tǒng)中有多個服務器，能夠分別提供不同的信息服務。其中，視頻服務器提供視頻數(shù)據(jù)服務，傳送的數(shù)據(jù)需要快速同步，但分辨率相對較低；圖?服務器提供圖?數(shù)據(jù)服務，數(shù)據(jù)需要以?分辨率發(fā)送；?錄服務器則提供?錄查詢服務，能夠?持各種查詢，并能夠與超?本信息進?鏈接。與集中式結構中的?智能終端不同，客戶機/服務器結構中的客戶機是具有智能的，需要安裝客戶程序，并需要通過客戶程序訪問服務器。例如5-3中的諸多客戶機，它們可以通過?個?戶界?客戶程序對服務器進?訪問，并可以通過這個?戶界?程序顯?從服務器返回的圖?或視頻信息。在客戶機/服務器結構中，客戶機是

主動的，它主動地向服務器提出服務請求；?服務器則是被動的，它被動地接受來?客戶機的請求。?般說來，客戶機在向服務器提出服務請求之前，需要事先知道服務器的地址與服務；但服務器卻不需要事先知道客戶機的地址，?是根據(jù)客戶機主動提供的地址向客戶機提供相應的服務。

客戶機/服務器結構的優(yōu)越性是結構靈活、便于系統(tǒng)逐步擴充。例如上?的多?戶超?本應?系統(tǒng)，也許?戶最初只需要提供圖?信息服務，因此系統(tǒng)初期開發(fā)時可以只創(chuàng)建圖?服務器，只是當?戶需要提供視頻信息服務時，才創(chuàng)建視頻服務器。顯然，這有利于應?系統(tǒng)的分階段實現(xiàn)與逐步擴充。另外，由于客戶機/服務器中服務器可以采??性能微機配置，因此其建設成本、運?費?等也明顯低于基于?型機的集中式結構。需要注意的是，客戶機/服務器結構是?種邏輯結構，客戶機或服務器都只是??概念。因此可以將客戶軟件和服務軟件安裝在?臺計算機上，?使這臺計算機既擔任客戶機??，?擔任服務器??。當然，也可以在?臺計算機上安裝多個服務軟件，?使這臺計算機承擔多個服務器??，例如，它可以既是圖?服務器，?是視頻服務器。

3多層客戶機/服務器結構

客戶機/服務器結構已被?泛應?基于數(shù)據(jù)庫的信息服務領域，并演變出了多層客戶機/服務器結構。圖5-4所?是?個有關信息管理應?的邏輯結構。這是?個三層邏輯結構，其中的表?層是指對?戶的信息服務；應?層是指對數(shù)據(jù)的應?邏輯加?；數(shù)據(jù)層是指系統(tǒng)中的數(shù)據(jù)庫管理。在集中式系統(tǒng)中，以上各個不同層?的元素都被部署在?臺主機上，這時或許沒有必要在它們之間清楚地劃分邊界。但值得注意的是，當采?客戶機/服務器結構時，這些元素卻有可能要被分布到不同的計算機上去，因此必須在它們之間給出?個清楚的邊界。

（1）兩層結構

兩層客戶機/服務器結構是將信息表?與應?邏輯處理都放在了客戶機上，?服務器只需要管理數(shù)據(jù)庫事務，其結構如圖5-5所?。這時的客戶機?般被稱為“胖客戶機”。

兩層結構的優(yōu)點是結構簡單，技術上?較容易實現(xiàn)。?且應?軟件基本上是在客戶端?作，因此?常?便客戶端數(shù)據(jù)的計算與表現(xiàn)，能夠有效保證系統(tǒng)的?作性能。兩層結構的缺陷是在管理與維護上存在困難。這時的客戶端承擔了信息表?與應?計算雙重任務，客戶端程序復雜，并且被分散在許多不同的客戶計算機上。除?應?軟件的功能?常穩(wěn)定或客戶端?很少，否則當應?軟件由于?戶應?規(guī)則的變化，?不得不對其功能進?改造時，系統(tǒng)中數(shù)?龐?的客戶機群，將會使系統(tǒng)變更顯得?常?煩，需要很?的系統(tǒng)變更開銷。

（2）三層結構

三層結構是鑒于兩層客戶機/服務器結構在管理與維護上存在的困難?專門提出的，這就是使“胖客戶機”減肥，使它盡量簡單，變成“瘦客戶機”。更具體地說，就是將“胖客戶機”中?較復雜，并且容易發(fā)?變化的應?邏輯部分提取出來，將它放到?個專門的“應?服務器”上，由此產(chǎn)?的結構如圖5-6所?。

顯然，三層結構使信息表?、應?邏輯處理和數(shù)據(jù)庫管理被?然地分成了三個獨?的部分。其中，應?邏輯處理是應?系統(tǒng)中的最易發(fā)?需求改變的部分，被放到了應?服務器上。與兩層結構?較，三層結構給系統(tǒng)維護帶來了很?的便利，當?戶應?規(guī)則發(fā)?變化時，需要改變的不是數(shù)?龐?客戶端，?是?個或少數(shù)?個應?服務器。但是，三層結構使實現(xiàn)軟件的技術難度加?、開發(fā)周期延長，并且對服務器設備也有更?的要求。需要指出的是，三層客戶機/服務器結構也是邏輯結構，因此?個單?的服務器計算機可以既是應?服務器，?是數(shù)據(jù)庫服務器。然?許多情況下，為了使系統(tǒng)具有更?的性能指標，或使系統(tǒng)具有更好的穩(wěn)定性，系統(tǒng)中?都分別設置有專門的應?服務器和數(shù)據(jù)庫服務器。?在?些實際開發(fā)中，為了使應?服務器能夠承擔來?于許多客戶機的計算請求，還往往需要根據(jù)軟件系統(tǒng)的計算負荷狀態(tài)，對應?服務器進?專門的配置設計，例如，按事務進?任務分?，并在系統(tǒng)中設置多臺專門應?服務器，它們分別完成?些特定的服務請求任務。

（3）B/S結構

B/S結構是基Web技術與客戶機/服務器結構的結合?提出來的?種多層結構，其中B是Web瀏覽器（Browse），S是指應?服務器與數(shù)據(jù)服務器（Server）。?前，這種結構已被?泛應?于?絡商務系統(tǒng)之中，例如?上銀?、?上商店等。其結構圖如5-7所?B/S結構將信息表?集中到了專門的“Web服務器”上。因此，與三層客戶機/服務器結構?較，B/S結構多了?層服務器。應該說，B/S結構使客戶端程序更加簡化。這時的客戶機上已經(jīng)不需要專門的應?程序了，只要有?個通?Web瀏覽器（例如，MicrosoftInternetExplorer），就可以實現(xiàn)客戶端數(shù)據(jù)的應?。

B/S結構的優(yōu)點是不需要對客戶機進?專門的維護（客戶機上沒有專門的應?程序），特別適合于客戶機位置不固定或需要依靠互聯(lián)?進?數(shù)據(jù)交換的應?系統(tǒng)。缺點是最終?戶信息需要通Web服務器獲取，并通過?絡傳送到客戶機上，因此系統(tǒng)的數(shù)據(jù)傳輸速度以及系統(tǒng)的穩(wěn)定性，都將明顯低于三層客戶機/服務器結構。如同其他客戶機/服務器結構?樣，B/S結構也是邏輯結構，因此?個單?的服務器計算機可以既Web服務器，?是應?服務器和數(shù)據(jù)庫服務器。但如果需要使系統(tǒng)具有更?的性能或更加穩(wěn)定的運?狀態(tài)，那么則有必要Web服務、應?處理和數(shù)據(jù)管理從物理上分離開來，設置專門Web服務器計算機、應?服務器計算機和數(shù)據(jù)庫服務器計算機。在許多應?中，B/S結構和三層客戶機/服務器往往被結合起來使?。例如“?上購物系統(tǒng)”，其?向消費者的購物操作?般采?的B/S結構，但?向購物中??作?員的相關操作，為了保證系統(tǒng)運?穩(wěn)定快捷，則可能會采?三層客戶機/服務器結構。其對應的物理構架如5-8所?。

B/S結構的優(yōu)點是不需要對客戶機進?專門的維護（客戶機上沒有專門的應?程序），特別適合于客戶機位置不固定或需要依靠互聯(lián)?進?數(shù)據(jù)交換的應?系統(tǒng)。缺點是最終?戶信息需要通Web服務器獲取，并通過?絡傳送到客戶機上，因此系統(tǒng)的數(shù)據(jù)傳輸速度以及系統(tǒng)的穩(wěn)定性，都將明顯低于三層客戶機/服務器結構。如同其他客戶機/服務器結構?樣，B/S結構也是邏輯結構，因此?個單?的服務器計算機可以既Web服務器，?是應?服務器和數(shù)據(jù)庫服務器。但如果需要使系統(tǒng)具有更?的性能或更加穩(wěn)定的運?狀態(tài)，那么則有必要Web服務、應?處理和數(shù)據(jù)管理從物理上分離開來，設置專門Web服務器計算機、應?服務器計算機和數(shù)據(jù)庫服務器計算機。在許多應?中，B/S結構和三層客戶機/服務器往往被結合起來使?。例如“?上購物系統(tǒng)”，其?向消費者的購物操作?般采?的B/S結構，但?向購物中??作?員的相關操作，為了保證系統(tǒng)運?穩(wěn)定快捷，則可能會采?三層客戶機/服務器結構。其對應的物理構架如5-8所?。

（4）組件對象分布式結構

組件是?個對象包。組件對象分布式結構就是通過組件?使軟件系統(tǒng)中的組件對象被分布到?絡上的多臺計算機上。組件對象具有?些公共接?，能夠向外提供服務，不同組件的對象之間可以通過公共接?相互通信和協(xié)同?作。應該說，傳統(tǒng)的客戶機/服務器結構是?種不對稱的分布式結構，其客戶機和服務器具有不同的地位?？蛻魴C能夠接受來?服務器的服務，但不能接受其他客戶機的服務；服務器能夠扮演客戶機的??，由此接受來?其他服務器的服務，但它不能請求來?客戶機的服務。然?，組件對象分布式結構則是?種?較對稱的結構，在這種結構中，已經(jīng)沒有了客戶機與服務器之間的界限，這些對象既可充當服務器，也可充當客戶機，其??只是決定于它是在提供服務還是在請求服務。

組件對象分布式結構是基于對象中間件建?的。主要?于對象分布式計算的中間件有：

?CORBA（通?對象請求代理模型）：由對象管理組織（OMG）定義，提供了?組通?的與機器?關的分布式對象計算?法?？?Unix、Linux或Windows上。

?DCOM（分布式組件對象模型）：由微軟公司定義，主要?在微軟公司的操作系統(tǒng)上?？梢园褜ο笾虚g件看成是能夠在其上插拔組件的軟件總線。這就像硬件總線允許不同的接?卡插于其上以?持硬件設備之間的通信?樣，對象中間件作為軟件總線，也允許在其上添加或移?組件對象，或進?組件對象之間的相互通信。其邏輯結構如5-9所?。

應該說，組件對象分布式結構是?個開放的體系構造，它不僅允許新的組件對象根據(jù)需要增加進來，?且還允許使?不同語?編寫的對象。現(xiàn)在，組件對象分布式結構已經(jīng)成為構造軟件系統(tǒng)的?種基本模式，諸多運?在互聯(lián)?上的遠程服務系統(tǒng)，它們即是按照這種結構構造的。在應?系統(tǒng)中采?組件對象分布式結構時，可依照以下步驟來進?系統(tǒng)結構設計：

（1）按照系統(tǒng)功能服務對系統(tǒng)進?邏輯分塊，確定系統(tǒng)的邏輯構造。

（2）以系統(tǒng)邏輯構造為依據(jù)，設計系統(tǒng)的分布式組件對象。

（3）以組件之間的通信與協(xié)作為依據(jù)，對組件進?物理部署。

組件對象分布式結構具有靈活的構架，系統(tǒng)伸縮性好，能夠給系統(tǒng)的功能調整與擴充帶來便利。但是，采?完全分布的組件對象結構，其技術難度太?，內部結構也較復雜。相?之下，客戶機/服務器結構是?種更加容易理解的結構，并與現(xiàn)實的組織機構、業(yè)務過程具有?致性。因此，在許多實際應?中，往往將組件對象分布式結構與客戶機/服務器結構結合起來，其中組件對象分布式結構被作為?種實現(xiàn)技術嵌?到客戶機/服務器系統(tǒng)之中。這種構架的特點是：系統(tǒng)先按照客戶機/服務器結構進?邏輯構造；然后?論是客戶機還是服務器，都按照組件對象分布式結構進?內部構造設計，它們都由組件組成，并都需要通過對象中間件實現(xiàn)通信。顯然，這樣的系統(tǒng)將更加具有柔性，系統(tǒng)的變更也將會變得更加容易。例如，?個?層客戶機/服務器結構，只需要對其組件對象進?重新部署，就可以將其改造成為三層甚?多層客戶機/服務器結構。實際上，分布式組件對象技術能夠給應?服務器的創(chuàng)建帶來更好的可伸縮性，由諸多組件構造的應?服務器可以更加?由地進?物理部署。例如?個供銷管理系統(tǒng)，假設其包括供應商聯(lián)系、庫存控制、客戶聯(lián)系、貨物訂購等業(yè)務內容，并且這些業(yè)務都由?個供銷部門負責，則系統(tǒng)構造可按以上業(yè)務創(chuàng)建組件，并將這些組件部署在?臺應?服務器上，如5-10所?。

但假如業(yè)務流程發(fā)?了變化，例如，由于業(yè)務量擴?，該供銷部門需要拆分為供應部、銷售部兩個部門時，考慮到業(yè)務歸?與服務器負荷的影響，上?的?臺應?服務器也需要改變?yōu)閮膳_應?服務器，分別承擔供應與銷售的事務處理。顯然，系統(tǒng)所采?的組件對象分布式結構能夠很?便地適應這種業(yè)務需求的變更，需要進?的系統(tǒng)改造只不過是將?于業(yè)務處理的組件重新進?部署或安裝，如5-11所?。

三、軟件結構設計

軟件結構設計是對組成系統(tǒng)的各個?系統(tǒng)的進?步分解與規(guī)劃。例如，將?系統(tǒng)按照其功能要素分解成具有?定的功能邊界的模塊，然后以模塊為單位來構造軟件。顯然，需求分析階段已經(jīng)建?起的有關系統(tǒng)的功能模型、數(shù)據(jù)模型或狀態(tài)機模型，可以作為軟件結構設計的前提依據(jù)。具體說來，軟件結構設計包括以下???的內容：

（1）確定構造?系統(tǒng)的模塊元素。

（2）定義每個模塊的功能。

（3）定義模塊接?，設計接?的數(shù)據(jù)結構。

（4）確定模塊之間的調?與返回關系。

（5）評估軟件結構質量，進?結構優(yōu)化。

1.模塊概念

（1）模塊化

模塊概念產(chǎn)?于結構化程序設計思想，這時的模塊被作為構造程序的基本單元，例如函數(shù)、過程。在結構化?法中，模塊是?個功能單位，因此模塊可?可?。它可以被理解為所建軟件系統(tǒng)中的?個?程序系統(tǒng)，也可以是?程序系統(tǒng)內?個涉及多項任務的功能程序塊，并可以是功能程序塊內的?個程序單元，例如函數(shù)、過程。也就是說，模塊實際上體現(xiàn)出了系統(tǒng)所具有的功能層次結構。模塊可以使軟件系統(tǒng)按照其功能組成進?分解，?通過對軟件系統(tǒng)進?分解，則可以使?些?的復雜的軟件問題分解成諸多?的簡單的軟件問題。從軟件開發(fā)的?度來看，這必然有利于軟件問題的有效解決。對于這個結論，可以進?以下論證：現(xiàn)假設函C（P）?于度量問P的復雜程度，函E（P）?于度量為解決問P所需要的?作量（?時間計算）。并假設有兩個問P和P。如果有C（P）>C（P）則必有E（P）>E（P）這是?個顯?易見的經(jīng)驗性結論。它表明：問題越復雜，解決這個問題所需要的?作量就越?，需要花費時間就越多。另?個來源于經(jīng)驗的結論是C（P1+P2）>C（P）+C（P）它表明：如果能夠把兩個結合在?起的問題隔離開來單獨解決，則可以使這原本結合在?起的問題的復雜程度下降。顯然，從上?兩個經(jīng)驗性結論中可以作出以下推論E（P1+P）>E（P）+E（P）它表明：如果能夠把兩個結合在?起的問題隔離開來單獨解決，則可以使這原本難于解決的問題變得容易解決起來。這個結論就是模塊化的基本依據(jù)，其作?就是能夠使?的復雜的問題被“各個擊

破”。上述結論表明：模塊化可以使軟件問題簡化。但是，得出這個結論需要有下?的前提條件：?模塊被分解成諸多?模塊之后，?模塊基本上處于相互隔離的獨?狀態(tài)，它們之間沒有太多的通信。否則，?模塊之間由于存在太多的通信，將會導致?模塊接?復雜起來，其結果是，雖然每個模塊內部簡化了，但整個軟件問題反?復雜起來。許多?都有?個良好的愿望，那就是依靠模塊化使系統(tǒng)不斷分解?使整個系統(tǒng)不斷簡化，由此使軟件開發(fā)成本不斷下降。然?這卻可能做不到，因為隨著系統(tǒng)的分解，系統(tǒng)中模塊數(shù)?將會增加，模塊接?也會增加，軟件構造會由此變得復雜起來，模塊連接的難度也會由此加?。實際上還有?個因素也在阻礙著這個愿望的實現(xiàn)，這就是軟件系統(tǒng)的模塊化分解本?也是?件并不輕松的?作，假如分解系統(tǒng)所需要的?作量，已經(jīng)超過因為模塊簡化?減少的?作量，那就意味著，進?步分解系統(tǒng)已是?件得不償失的事情了。因此，軟件系統(tǒng)模塊化分解，從軟件成本?度來看，有?個最?成本模塊數(shù)范圍。如5-12所?，若分解程度低于這個最?成本模塊數(shù)范圍，則可繼續(xù)分解，以降低軟件開發(fā)成本；但若分解程度已經(jīng)達到這個最?成本模塊數(shù)范圍，則就沒有必要再進?分解了，否則將會反?增加軟件開發(fā)的成本。

（2）抽象化

抽象是?所具有的?種?級思維活動，是以概括的?式抽取?系列事物的共同特征，由此把握事物的本質屬性。抽象也是?類解決復雜問題時強有?的?段，能夠使?從事物復雜的外部表象中發(fā)現(xiàn)事物的內在本質規(guī)律，由此找到解決問題的有效途徑。這種抽象的?法也被運?于軟件?程之中。實際上，軟件?程的每?個階段，都能夠看到抽象思維?法的作?，從軟件的定義到軟件的設計，直到軟件編碼與最終實現(xiàn)。但是，在軟件?程的不同階段，抽象層次與對象卻各不相同，并需要運?不同的語?進?描述。例如，在軟件分析階段，抽象對象是系統(tǒng)的外部特征，需要采?的描述語?是軟件問題所處環(huán)境中的?戶術語；?在設計階段，抽象對象則是系統(tǒng)的內部構造，需要采?的描述語?則是更加規(guī)范的適合于系統(tǒng)構造的過程化語?。概要設計中的功能模塊往往被看成是?個抽象化的功能?盒?，其特征如5-13所?。雖然它已是?個與軟件實現(xiàn)直接相關的實體單元，可以看到它清晰的外觀，但是卻看不到它內部更加具體的實現(xiàn)細節(jié)。抽象的作?是對事物現(xiàn)象的?度概括，但抽象的最終?的則是?到它的對??，產(chǎn)?出具體的結果。因此，?個完整的抽象化過程是既包含抽象?包含具體的循環(huán)演變過程。應該說，正是由抽象到具體的不斷演變，才使得?的抽象認識能夠不斷地產(chǎn)?出有意義的結果，并不斷地推動著?類思想的進步。這種由抽象到具體的不斷演變也?直貫穿于軟件?程過程之中，這就是?頂向下、逐步細化，其中，頂是抽象的，?細化則是這個抽象的頂具體化的結果。這意味著，軟件?程的每?個階段的推進，都具有從抽象到具體的轉化。例如需求分析，它建?在可?性研究基礎之上?？?性研究所獲得的是有關整個計算機系統(tǒng)的外部模型，這是?種對整個系統(tǒng)的?度抽象。但是，隨著需求分析的進?，可?性研究中?度抽象的系統(tǒng)模型被逐步地轉變成需求分析模型中每?個功能局部的規(guī)格定義。顯然，這是軟件從?層定義到低層定義的具體化演變。?如概要設計，它是在需求分析基礎上進?的，需要根據(jù)需求分析中的基本要求設計軟件系統(tǒng)的基本構架，需要按照需求分析所提出的功能規(guī)格，確定軟件系統(tǒng)中模塊的構成，定義模塊的接?，確定模塊之間通信，設計對模塊的控制。顯然，這是軟件從系統(tǒng)定義到系統(tǒng)設計的具體化演變。應該說，概要設計中的結論，對于軟件內部構造??則仍是抽象的。?如概要設計中的功能模塊，盡管它有惟?的名稱標識，有明確的功能定義，并設置有數(shù)據(jù)的輸?輸出接?。但是，模塊的內部實現(xiàn)細節(jié)則處于待定狀態(tài)，需要等到詳細設計完成以后才能得出更加具體的算法結論。

（3）信息隱藏

設計軟件結構時?個不可回避的問題是：為了得到?種?質量的模塊組合，應該如何分解軟件。對此，不得不了解什么是“信息隱蔽”。信息隱蔽是指每個模塊的內部實現(xiàn)細節(jié)對于其他模塊來說是隱蔽的。也就是說，模塊中所包含的信息，例如，模塊內部的數(shù)據(jù)、語句或過程等，不允許其他不需要這些信息的模塊使?。顯然，信息隱蔽有利于模塊相互之間的隔離，可以使每個模塊更加具有獨?性，并可以使模塊之間的通信受到限制。例如，模塊之間只能傳遞那些對于其功能實現(xiàn)??是必須的信息。通過限制模塊需要使?的數(shù)據(jù)的作?范圍，例如，定義模塊內部局部變量，可以產(chǎn)?出模塊內部信息隱蔽的效果。模塊內部信息隱蔽的好處是可以使軟件系統(tǒng)更加健壯，更加?便維護。以模塊中的錯誤為例，假如模塊內部信息是隱蔽的，則模塊中存在的這個錯誤將?較難于擴散到其他模塊。否則，系統(tǒng)可能因為?個?錯誤的擴散，?使整個系統(tǒng)崩潰。實際上，信息隱蔽還使軟件錯誤定位更加?便。由于軟件出錯位置容易發(fā)現(xiàn)，因此，整個軟件糾錯?作的效率、質量都會隨之提?。?些模塊的功能有時需要根據(jù)?戶需求的變更?適時地進??些功能改造。當需要對模塊進?功能改造時，模塊內部的信息隱蔽會使對模塊改造所帶來的影響限制在需要改造的模塊之內，?與其他模塊?關。顯然，這將使軟件系統(tǒng)的局部修改變得更加便利。

2.模塊的獨?性

模塊的獨?性是指軟件系統(tǒng)中每個模塊都只涉及??特定的?功能，并且模塊接?簡單，與軟件中其他模塊沒有過多的聯(lián)系。

模塊獨?性是衡量軟件中模塊質量最重要的指標，是設計與優(yōu)化軟件結構時必須考慮的重要因素。當軟件中的每個模塊都具有很好的獨?性時，軟件系統(tǒng)不僅更加容易實現(xiàn)，并且會使今后的維護更加?便。模塊的獨?性?般采?耦合和內聚這兩個定性的技術指標進?度量。其中，耦合?來反映模塊之間互相連接的緊密程度，模塊之間的連接越緊密，聯(lián)系越多，耦合性就越?。內聚?來反映模塊內部各個元素彼此結合的緊密程度，?個模塊內部各個元素之間結合越緊密，則它的內聚性就越?。顯然，為了使模塊具有較強的獨?性，要求模塊是?內聚、低耦合。

（1）耦合

耦合是軟件結構中各個模塊之間相互關聯(lián)程度的度量。耦合的強弱取決于各個模塊之間接?的復雜程度、接?數(shù)據(jù)對模塊內部計算的影響程度和調?模塊的?式。模塊之間的耦合形式主要有：?直接耦合、數(shù)據(jù)耦合、控制耦合、公共耦合和內容耦合。其中，?直接耦合和數(shù)據(jù)耦合是較弱的耦合，控制耦合和公共耦合是中等程度的耦合，內容耦合則是強耦合。模塊化設計的?標是盡量建?模塊間耦合松散的系統(tǒng)。因此，在設計軟件結構時?般也就要求盡量采??直接耦合和數(shù)據(jù)耦合，少?或限制使?控制耦合和公共耦合，絕對不能使?內容耦合。為了更好地認識模塊之間的耦合，下?將對上述各種耦合形式給出必要說明。

a.?直接耦合

如果兩個模塊之間沒有直接關系，它們之間的聯(lián)系僅限于受到共同主模塊的控制與調?，則稱這種耦合為?直接耦合。由于?直接耦合的模塊之間沒有數(shù)據(jù)通信，因此模塊的獨?性最強。

b.數(shù)據(jù)耦合

當?個模塊訪問另?個模塊時，如果彼此之間是通過模塊接?處的參數(shù)實現(xiàn)通信，并且參數(shù)所傳遞的數(shù)據(jù)僅?于計算，?不會影響傳?參數(shù)模塊的內部程序執(zhí)?路徑，則稱這種耦合為數(shù)據(jù)耦合。數(shù)據(jù)耦合是?種松散的耦合。依靠這種類型的耦合，模塊之間既能實現(xiàn)通信，?有?較強的獨?性。因此，軟件結構設計中提倡使?這類耦合

c.控制耦合

當?個模塊訪問另?個模塊時，如果彼此之間是通過模塊接?處的參數(shù)實現(xiàn)通信，并且參數(shù)傳遞了開關、標志、名字等控制信息，由此影響了傳?參數(shù)模塊的內部程序執(zhí)?路徑，則稱這種耦合為控制耦合如5-14所?。由于接?參數(shù)影響著內部程序執(zhí)?路徑，因此控制耦合?數(shù)據(jù)耦合要強?些，會使模塊的獨?性有所下降。當需要通過?個單?的接?傳遞模塊內多項功能的選擇信息時，往往需要?到控制耦合。顯然，在控制耦合形式下，對所控制模塊的修改，需要受到控制參數(shù)的限制。

d.公共耦合公共耦合是?種通過訪問公共數(shù)據(jù)環(huán)境?實現(xiàn)通信的模塊耦合形式，例如，獨?于模塊?存在的數(shù)據(jù)?件、數(shù)據(jù)表集、公共變量等，都可以看作為公共數(shù)據(jù)環(huán)境。公共耦合中的公共數(shù)據(jù)環(huán)境是提供給任何模塊的，當模塊之間的耦合是公共耦合時，那些原本可以依靠接?提供的對數(shù)據(jù)的限制也就沒有了。因此，相?依靠接?的耦合形式，公共耦合必然會使模塊的獨?性下降。也正因為如此，實際應?中，只有在模塊之間需要共享數(shù)據(jù)，并且通過接?參數(shù)傳遞不?便時，才使?公共耦合。需要注意的是：模塊之間公共耦合的復雜程度，將會隨著耦合模塊個數(shù)的增加?顯著增加。為了降低公共耦合帶來的復雜性和提?模塊的獨?性，實際應?中還會針對公共耦合專門設置?些限制，例如不使?公共耦合數(shù)據(jù)傳遞控制信息。圖5-15中的模塊采?了訪問公共數(shù)據(jù)環(huán)境的公共耦合形式。其中圖（a）是?個模塊只往公共數(shù)據(jù)環(huán)境?送進數(shù)據(jù)，另?個模塊只從公共數(shù)據(jù)環(huán)境中取出數(shù)據(jù)，這是?種?較松散的公共耦合；?圖（b）則是兩個模塊都可以向公共數(shù)據(jù)環(huán)境?送進數(shù)據(jù)，?都可以從公共數(shù)據(jù)環(huán)境中取出數(shù)據(jù)，這就是?種?較緊密的公共耦合。

另外，公共耦合還會帶來以下?些??的影響?由于所有公共耦合模塊都會與某?個公共數(shù)據(jù)環(huán)境有關，因此修改公共數(shù)據(jù)環(huán)境中某個數(shù)據(jù)的結構，將會影響到所有被耦合的模塊。

?由于沒有辦法控制各個模塊對公共數(shù)據(jù)的存取，因此公共耦合會影響軟件模塊的可靠性和適應性。

?由于公共數(shù)據(jù)環(huán)境需要被許多模塊使?，因此不得不使?具有公共意義的數(shù)據(jù)名稱。顯然，這會使得程序的可讀性有所下降。

e.內容耦合如果發(fā)?下列情形，兩個模塊之間就發(fā)?了內容耦合。

??個模塊直接訪問另?個模塊的內部數(shù)據(jù)。

??個模塊不通過正常??轉到另?模塊內部?兩個模塊有?部分程序代碼重疊。

??個模塊有多個??。內容耦合是?種?常強的耦合形式，嚴重影響了模塊獨?性。當模塊之間存在內容耦合時，模塊的任何改動都將變得?常困難，?旦程序有錯則很難修正。因此，設計軟件結構時，也就要求絕對不要出現(xiàn)內容耦合。所幸的是，?多數(shù)?級程序設計語?已經(jīng)設計成不允許出現(xiàn)內容耦合，它?般只會出現(xiàn)在匯編語?程序中。

（2）內聚

內聚是對模塊內部各個元素彼此結合的緊密程度的度量。模塊內部各個元素之間的聯(lián)系越緊密，則它的內聚程度就越?。模塊的設計?標是盡量使模塊的內聚程度?，以達到模塊獨?、功能集中的?的。模塊內聚的主要類型有：功能內聚、信息內聚、通信內聚、過程內聚、時間內聚、邏輯內聚和偶然內聚，如5-16所?。其中，功能內聚和信息內聚屬于?內聚，通信內聚和過程內聚屬于中等程度的內聚，時間內聚、邏輯內聚和偶然內聚則屬于低內聚；?且，模塊內聚程度越?，其功能越集中、獨?性越強。

內聚所體現(xiàn)的是模塊的內部功能構造，耦合所體現(xiàn)的是模塊之間的聯(lián)系。?般情況下，內聚和耦合是相互關聯(lián)的，模塊的內聚程度越?，則模塊間的耦合程度就會越低，但這也不是絕對的。值得指出的是，?起模塊之間的耦合來，模塊的內聚更顯重要。因此，實際設計中應當把更多的注意?放在如何提?模塊的內聚程度上。模塊內聚的提?依賴于對模塊功能的正確認識，應該通過定義使每?個模塊都具有明確的功能。為了更好地認識模塊內聚，下?將對上述?種內聚類型分別加以說明。

a.偶然內聚

當模塊內各部分之間沒有聯(lián)系，或即使有聯(lián)系，這種聯(lián)系也很松散時，將會出現(xiàn)偶然內聚。偶然內聚往往產(chǎn)?于對程序的錯誤認識或沒有進?軟件結構設計就直接編程。例如，?些編程?員可能會將?些沒有實質聯(lián)系，但在程序中重復多次出現(xiàn)的語句抽出來，組成?個新的模塊，這樣的模塊就是偶然內聚模塊。偶然內聚模塊由于是隨意拼湊?成，模塊內聚程度最低、功能模糊，很難進?維護。

b.邏輯內聚

邏輯內聚是把?種相關的功能組合在?起形成為?個模塊。在調?邏輯內聚模塊時，可以由傳送給模塊的判定參數(shù)來確定該模塊應執(zhí)?哪?種功能。例如5-17中的打印模塊。邏輯內聚模塊?偶然內聚模塊的內聚程度要?，因為它表明了各部分之間在功能上的相關關系。但是它每次執(zhí)?的不是?種功能，?是若?功能中的?種，因此它不易修改。另外，在調?邏輯內聚模塊時，需要進?控制參數(shù)的傳遞，由此增加了模塊間的耦合。

c.時間內聚

時間內聚模塊?般是多功能模塊，其特點是模塊中的各項功能的執(zhí)?與時間有關，通常要求所有功能必須在同?時間段內執(zhí)?。例如初始化模塊，其功能可能包括給變量賦初值、連接數(shù)據(jù)源、打開數(shù)據(jù)表、打開?件等，這些操作要求在程序開始執(zhí)?的最初?段時間內全部完成。時間內聚模塊?邏輯內聚模塊的內聚程度?稍??些，其內部邏輯?較簡單，?般不需要進?判定轉移。

d.過程內聚

如果?個模塊內的處理是相關的，?且必須以特定次序執(zhí)?，則稱之為過程內聚模塊。在使?流程圖設計程序的時侯，常常通過流程圖來確定模塊劃分，由此得到的就往往是過程內聚模塊。例如，可以根據(jù)流程圖中的循環(huán)部分、判定部分和計算部分將程序分成三個模塊，這三個模塊就是過程內聚模塊。過程內聚模塊的內聚程度?時間內聚模塊的內聚程度更強?些，但過程內聚模塊僅包括完整功能的?部分，因此模塊之間的耦合程度?較?。

e.通信內聚

如果?個模塊內各功能部分都使?了相同的輸?數(shù)據(jù)或產(chǎn)?了相同的輸出數(shù)據(jù)，則稱之為通信內聚模塊。例如5-18中的處理?資模塊。通信內聚模塊由?些獨?的功能組成，因此其內聚程度?過程內聚程度要?。

f.順序內聚

如果?個模塊內的諸多功能元素都和某?個功能元素密切相關，?且這些功能元素必須順序安排（前?項功能的數(shù)據(jù)輸出作為后?項功能的數(shù)據(jù)輸?），則稱之為順序內聚模塊。當根據(jù)數(shù)據(jù)流圖劃分模塊時，由此得到的通常就是順序內聚模塊。例如5-19中的?庫統(tǒng)計模塊。順序內聚模塊也包含著多項功能，但它有?個核?功能，其他功能則圍繞著這個核??安排。因此，順序內聚程度?通信內聚程度更?。

g.功能內聚

如果?個模塊中各個部分都是完成某?具體功能必不可少的組成部分，各個部分協(xié)同?作、緊密聯(lián)系、不可分割，則稱該模塊為功能內聚模塊。功能內聚模塊的特征是功能單?、接?簡單，因此其容易實現(xiàn)、便于維護。與其他內聚類型相?，功能內聚具有最?的內聚程度，軟件結構設計時應以其作為追求?標。

3結構化設計建模

軟件結構設計涉及模塊功能、模塊接?與模塊調?關系等問題，為了使這些問題能夠集中清晰地表達出來，軟件結構設計需要借助于?定的圖形?具來建?設計模型，例如軟件結構圖HIPO圖。

（1）軟件結構圖

軟件結構圖Yourdon于20世70年代提出，并被?泛應?于軟件結構設計中，能夠有效說明軟件中模塊之間的調?與通信。軟件結構圖使?矩形框表?模塊（框內注明模塊的名字或主要功能），使?帶箭頭的直線段連接上下級模塊，以表?上級模塊對下級模塊的調?。此外，軟件結構圖還可以在調?箭頭旁使?帶注釋的箭頭，以表?上級模塊在調?下級模塊時參數(shù)的傳遞與結果的返回，其基本圖形符號如5-1所列。表

圖5-20是?個?動閱卷系統(tǒng)的軟件結構圖。閱卷總控模塊為頂層模塊，其調?考卷數(shù)據(jù)輸?、閱卷處理和考卷成績輸出這三個模塊，以進?考卷輸?、成績計算和成績輸出的控制。在更下?級模塊調?中，考卷數(shù)據(jù)輸?模塊通過調?讀答卷卡模塊將考卷原始數(shù)據(jù)輸?，然后調?檢驗考卷數(shù)據(jù)模塊產(chǎn)?出適合評分計算的有效數(shù)據(jù)；考卷成績輸出模塊則通過調?格式化成績數(shù)據(jù)模塊對計算出的成績數(shù)據(jù)進?輸出前的格式化處理，然后調?寫成績記錄模塊實現(xiàn)成績的存檔操作。

（2）HIPO圖

HIPO圖是美IBM公司推出的“H圖”與“IPO圖”的組合。

a.H圖

H圖是軟件層次圖的簡稱，?于描述軟件結構上的分層調?關系，作?類似于軟件結構圖，但不涉及調?時的數(shù)據(jù)流、控制流等附加信息H圖的優(yōu)點是清晰度?，能夠?于正式?檔中對軟件結構的描述。5-21是?動閱卷系統(tǒng)的H圖，可以看出，它?上?的軟件結構圖要清晰得多。為了能H圖中的模塊具有可追蹤性，由此可以與它所對應IPO圖聯(lián)系起來。圖中模塊除了最頂層的之外，其他的模塊都需要按照?定的規(guī)則編號，以?便檢索。

b.IPO圖

IPO圖是“輸?—處理—輸出圖”的簡稱，其中的“I”是指輸?，“O”是指輸出，“P”是指處理?？梢允笽PO圖對模塊進?外部特征描述，涉及輸?、輸出接?和基本加?步驟等。在HIPO圖中，需要針H圖中的每個模塊給IPO圖描述。

從上?IPO圖舉例可以看到，IPO圖提供了有關模塊的更加完整的定義和說明。顯然，這將有利于由概要設計到詳細設計的過渡。

4.軟件結構優(yōu)化

軟件結構設計往往需要經(jīng)歷多次反復，其作?是可以不斷地改進軟件結構，提?軟件質量。為了改進軟件結構，軟件設計?員進?了長期的實踐與總結，由此得到了?些優(yōu)化設計的原則。本節(jié)將介紹這些原則。

（1）使模塊功能完整

?個完整的功能模塊，不僅能夠完成指定的功能，?且還應當能夠將完成任務的狀態(tài)通知使?者。具體說來，?個完整的功能模塊應當包含以下?個部分的內容：

a.執(zhí)?規(guī)定功能的部分。

b.出錯處理的部分。當模塊不能完成規(guī)定的功能時，必須回送出錯標志，并向它的調?者報告出現(xiàn)這種例外情況的原因。

c.如果需要返回?系列數(shù)據(jù)給它的調?者，在完成數(shù)據(jù)加?時，應當給它的調?者返回?個該模塊執(zhí)?是否正確結束的“標志”。

（2）使模塊??適中

許多情況下，可以?模塊中所含語句的數(shù)量的多少來衡量模塊的??。有?認為限制模塊的??也是減少模塊復雜性的有效?段之?，因?要求把模塊的??限制在?定的范圍之內，例如將模塊內的語句限制5～100?左右。當然，這只能作為參考。?般說來，模塊過?的原因往往是模塊的功能太多，因此有必要對?模塊做進?步的分解。?多數(shù)情況下，可以從?模塊中分解出?些下級模塊或同層模塊。軟件結構設計時，也有可能出現(xiàn)模塊過?的問題。如果模塊太?，則要注意這個模塊的功能是否完整，是否將?個完整的功能分解到多個模塊中去了。許多情況下，可以考慮將較?的模塊與調?它的上級模塊合并。如果模塊雖?但功能內聚性好，或者它為多個模塊所共享，或者調?它的上級模塊很復雜，則不要貿然將?模塊與其他模塊合并，?是需要做更加細致的分析。

（3）使模塊功能可預測

?個功能可預測的模塊可以被看成是?個“?箱”，?論內部處理細節(jié)如何，只要輸?數(shù)據(jù)是相同的，就總能產(chǎn)?相同的輸出結果。例如，在模塊中使?了靜態(tài)變量。因為靜態(tài)變量會在模塊內部產(chǎn)?較難預見的存儲，?如果這個靜態(tài)變量?被?為多項功能的選擇標記，則可能會使得模塊的功能難以被調?者預知。由于這個原因，設計者要特別慎重地使?靜態(tài)變量。模塊功能可預測還意味著，模塊的功能必須明確清晰地定義，應該使模塊具有很好的內聚性。

（4）盡量降低模塊接?的復雜程度

模塊接?是模塊與外界進?通信的通道，較復雜的接?往往會帶來較?的耦合。因此，應努?降低模塊接?的復雜程度。對此，可以從以下兩個??作出考慮。

a.接?參數(shù)盡量采?簡單數(shù)據(jù)類型，以使接?容易理解。例如，盡量使?基本字符、整數(shù)類型，?不是數(shù)組、指針、結合體類型。

b.限制接?參數(shù)的個數(shù)。接?參數(shù)個數(shù)太多，往往是由于模塊功能混雜，不得不依靠參數(shù)進?調控。因此，過多的參數(shù)往往意味著模塊還有進?步分解的必要。

（5）使模塊作?范圍限制在其控制范圍之內

模塊的控制范圍包括它本?及其所有從屬于它的直接或間接下級模塊。如5-24所?，模B的控制范圍是模E、F、G、K，模C的控制范圍是模H、I、L、K，模D的控制范圍是模、J、L。模塊的作?范圍則是指模塊內?個判定的影響范圍，凡是受這個判定影響的所有模塊都屬于這個判定的作?范圍。其中，如果?個判定的作?范圍包含在這個判定所在模塊的控制范圍之內，則這種結構是簡單的；否則，其結構就是不簡單的，需要進?結構調整。例如，5-24中的模。如果它做出?個判定之后，接著需要模G?作，由于模G不在模F控制范圍之內，因此模F必須返回?個信號給模B，再B把信號傳送給模。顯然這不是?個好的設計，它增加了模塊之間數(shù)據(jù)的傳送量，并使模塊之間出現(xiàn)了控制耦合，因此需要對其結構進?調整。

在設計過程中，如果發(fā)現(xiàn)模塊的作?范圍不在控制范圍之內時，可以采?如下辦法進?結構調整，把模塊的作?范圍移到其控制范圍之內。

（1）將判定所在的模塊合并到它的?模塊中去，或上移到層次較?的位置上去，由此可使判定處于?個較?的位置，以達到有效的控制。例如，將模F與模B合并，如5-25所?，由此可使模G受到控制。

（2）將受判定影響的模塊下移到控制范圍以內。例如，將模G下移到模F之下，如5-26所?，由此可使模G受到模F控制。需要注意的是：在改進模塊的結構時，應當根據(jù)具體情況通盤考慮，既要盡量?范圍地調整結構，使改進后的軟件結構能夠最好地體現(xiàn)問題的原來結構，?要考慮改進后的結構在實現(xiàn)上的可?性。

（6）深度、寬度、扇出和扇?應當適當

軟件的深度是指軟件結構的層數(shù)。例如，5-24中的軟件結構，其深度4層。

軟件的寬度是指軟件結構同?個層次上模塊的總個數(shù)的最?值。例如，5-24中的軟件結構，其第?層寬度，第三層寬度，第四層寬度是2。其整個軟件的寬度。軟件結構上的深度、寬度，在?定程度上反映出了軟件系統(tǒng)的規(guī)模和復雜程度。也就是說，軟件規(guī)模越?越復雜，其深度、寬度也會越?。?般說來，深度、寬度會受模塊的扇出、扇?影響，并應該有?個合適的??。深度、寬度太?，往往表?模塊分解得還不夠細，需要進?步分解。?深度、寬度太?，則可能表?模塊分解得太細?了，或功能冗余模塊太多了，以致軟件結構變得復雜起來。?般說來，軟件結構越復雜，模塊之間的耦合就會越?。因此，假如軟件結構過于復雜，就有必要將?些模塊進?適當?shù)暮喜ⅲ瑢⒛切┕δ芟嗤蛳嗨频哪K合并起來作為公共模塊使?。模塊的扇出是指模塊直接調?的下級模塊的個數(shù)。?較適當?shù)纳瘸鰯?shù)～5，?般不要超過。如果?個模塊的扇出過?，就表明該模塊具有過分復雜的控制功能，需要協(xié)調和控制過多的下屬模塊。對此，應當適當增加中間層次的控制模塊，將?較集中的控制分解開來，如5-27所?。但扇出過?也不好，這樣將使得軟件結構的深度??增加，會帶來過多的調?和返回的時間開銷，由此降低軟件的?作效率。

模塊的扇?是指模塊受到了多少個直接上級模塊的調?。?個模塊的扇?越?，則共享該模塊的上級模塊的數(shù)?就越多。如果?個模塊的扇?數(shù)太?，?它?不是公?模塊，則說明該模塊可能具有多項功能。在這種情況下，應當對它做進?步的分析，并將其功能做進?步的分解。

?般說來，各個不同層次的模塊具有以下特點：頂層模塊起全局控制作?；中間層次的模塊起局部控制作?，并適當承擔?些簡單的操作提?功能；底層模塊擔任具體加?任務。因此，?個設計得?較好的軟件結構通常應具有這樣的特征：頂層模塊?扇出，中層模塊低扇出，底層模塊?扇?。

四、?向數(shù)據(jù)流的結構設計

作為構造軟件的基本框架，軟件結構應該與需要分析時建?的分析模型保持?致。?種?常有效的設計思路是，基于需求分析中的數(shù)據(jù)流模型進?軟件結構映射，由此產(chǎn)?出軟件系統(tǒng)的基本設計模型。為了?便從數(shù)據(jù)流模型中映射出軟件結構來，需要對數(shù)據(jù)流進?合理的分類。例如，將數(shù)據(jù)流分為變換流或事務流，然后按照它們各?不同的特點分別采取不同的映射?法。

1.變換流分析與設計

（1）變換流

變換數(shù)據(jù)流所體現(xiàn)出的是數(shù)據(jù)從輸?到加?再到輸出的?般步驟。變換數(shù)據(jù)流對數(shù)據(jù)的加?流程如5-28所?，這就是數(shù)據(jù)?先需要經(jīng)過輸?過程，將外部數(shù)據(jù)形態(tài)轉變?yōu)檫m合進?加?處理的內部形態(tài)；然后經(jīng)過變換中?，將已轉成內部形態(tài)的輸?數(shù)據(jù)加?成?種新的數(shù)據(jù)形態(tài)；接著再經(jīng)過輸出過程，將經(jīng)過加?產(chǎn)?的新的數(shù)據(jù)結果轉換成適合向外導出的數(shù)據(jù)形態(tài)。

（2）?層框架

由于變換數(shù)據(jù)流將整個過程分割成了輸?、變換和輸出三個部分，因此，對軟件結構的映射也就可以是在總控模塊之下，將軟件分為輸?、變換、輸出三個部分。為了減輕總控模塊的控制負擔，可以針對這三個部分，分別設置控制模塊，由此獲得對各個區(qū)段的有效控制。

圖5-29是基于變換流的?層框架圖。

（3）下層模塊

當軟件結構的?層框架被確定下來以后，接著需要考慮的是那些涉及具體操作的下級模塊。為了確定下級模塊，并能夠按照?定規(guī)則將這些下級模塊掛接到上?的框架上去，有必要對變換數(shù)據(jù)流進?分段研究。

（1）輸?部分

?般情況下，可以把來源于外部端?的數(shù)據(jù)流稱為物理輸?點，?把由輸?過程進?到變換中?的數(shù)據(jù)流稱為邏輯輸?點。5-28中的輸?部分從“物理輸?點”到“邏輯輸?點”，其模塊掛接規(guī)則是從“邏輯輸?點”往“物理輸?點”進?搜索，所遇到的每?個處理框可以作為?個功能模塊依次掛接到“輸?控制”模塊之下。

（2）變換部分

圖5-28中的變換中?涉及“計1與“計2兩個處理框?？梢詫⑦@兩個處理框對應為功能模塊直接掛接到“變換控制”模塊之下。

（3）輸出部分

?般情況下，可以把由變換中?流向輸出過程的數(shù)據(jù)流稱為邏輯輸出點，?把由輸出過程流向外部端?的數(shù)據(jù)流稱為物理輸出點。5-28中的輸出過程從“邏輯輸出點”到“物理輸出點”，其模塊掛接規(guī)則是從“邏輯輸出點”往“物理輸出點”搜索，所遇到的每?個處理框可以當做?個模塊依次分層掛接。依照上述?法，可以獲得對5-28中的變換數(shù)據(jù)流的軟件結構映射，產(chǎn)?的軟件結構如圖5-30所?。

2.事務流分析與設計

（1）事務流

當輸?的數(shù)據(jù)流可以引發(fā)多個不同的事務活動流程，并且數(shù)據(jù)流圖中有?個明顯的事務調度中?時，這種數(shù)據(jù)流被稱為事務數(shù)據(jù)流。其特征如5-31所?。需要注意事務流中的事務調度中?與變換流中的變換中?的區(qū)別，事務調度中?并不對輸?數(shù)據(jù)進?加?，?只是根據(jù)不同的輸?數(shù)據(jù)作出不同的事務流程選擇。

（2）軟件結構

事務數(shù)據(jù)流以事務調度中?為核?，在此之前為接收事務，在此之后為事務分流處理。因此，基于事務流的軟件結構映射也就可以是在總控模塊之下將軟件分為接收事務與事務活動兩個部分。為了減輕總控模塊的控制負擔，可以針對這兩個部分分別設置控制模塊，例如“接收事務控制”模塊、“調度事務控制”模塊，以獲得對各個區(qū)段的有效控制。在事務流軟件框架確定以后，接著需要考慮其下層模塊的掛接。對此，以“事務調度中?”為起點，分別搜索事務輸?流與事務活動流，將所遇到的每?個處理框當做?個功能模塊依次掛接到“接收事務”模塊調度事務”模塊之下。依照上述?法，可以獲得對5-31中的事務數(shù)據(jù)流的軟件結構映射，產(chǎn)?的軟件結構如圖5-32所?。

3.混合流分析與設計

前?分別討論了變換分析與事務分析。其中，變換分析是軟件結構設計的主要?法，?部分軟件系統(tǒng)都可以按照變換分析?法進?設計。但是，在很多情況下僅使?變換分析是不夠的，還需要采?其他?法，事務分析就是?種?常有效的?法。例如商業(yè)數(shù)據(jù)處理系統(tǒng)，其主要組成部分就往往使?事務處理?法進?設計。軟件系統(tǒng)也可以是變換流與事務流的混合，如5-33所?為典型的變換流與事務流的混合。對于這樣的系統(tǒng)，通常采?變換分析為主、事務分析為輔的?式進?軟件結構設計。其?般設計思路如下：

（1）?先利?變換分析?法把軟件系統(tǒng)分為輸?、變換和輸出三個部分，由此設計出軟件系統(tǒng)的上層構架，例如頂層和第?層模塊。

（2）然后根據(jù)數(shù)據(jù)流圖各部分的結構特點，適當?shù)剡x擇變換分析或事務分析，由此設計出軟件系統(tǒng)的下層構架。如5-33中的混合數(shù)據(jù)流，即可以根據(jù)上述設計思路進?軟件結構映射，由此可以產(chǎn)?出如5-34所?的軟件結構初始?案。

4.設計舉例

問題：“郵件檢測與計價電?儀器系統(tǒng)”軟件結構設計。該問題數(shù)據(jù)流如5-35所?。這是?個典型的變換流問題，圖中數(shù)據(jù)流已被劃分為輸?、變換和輸出三個部分，并具有以下特征：

（1）輸?部分

有兩個輸??路。?路?：?于輸?與檢驗郵件投遞參數(shù)，包括郵件種類、投遞地區(qū)、郵資計價標準等參數(shù)；?路?：?于接收郵包傳感信號并檢測郵包，包括郵包重量、郵包封裝狀態(tài)、郵包違禁狀態(tài)等信號。

（2）變換部分

包括計算單件郵資、累計郵資、處理不合格郵包等變換處理，分別?于合格郵包的郵資計價和不合格郵包的處理提?。

（3）輸出部分

有四個輸出?路，包括：顯?單件郵資、顯?郵資總費?、打印票據(jù)、顯?不合格郵包處理提??；谏鲜鰧?shù)據(jù)流的分析，可以?便地根據(jù)變換流的結構映射規(guī)則產(chǎn)?出它所對應的軟件基本結構。該問題軟件結構如5-36所?。

5.數(shù)據(jù)庫結構設計

數(shù)據(jù)庫技術產(chǎn)?20世70年代初期，從這個時期起，數(shù)據(jù)庫技術經(jīng)歷了層次型、?狀型、關系型三種模型。在數(shù)據(jù)庫應?早期，由于層次型、?狀型具有的性能優(yōu)勢，它們占據(jù)了初期階段的主流位置。但20世80年代起，隨著計算機性能的迅速提?，關系型數(shù)據(jù)庫所具有的數(shù)學計算??的優(yōu)勢受到了重視，它逐漸成為主流數(shù)據(jù)庫，并得到了層次型、?狀型不曾有過的更加?泛的應?。例Oracl、SQLServer這些?熟能詳?shù)耐??型數(shù)據(jù)庫都是關系型數(shù)據(jù)庫。數(shù)據(jù)庫就是與特定主題或?標相聯(lián)系的信息的集合，例如?事數(shù)據(jù)庫、?資數(shù)據(jù)庫等。數(shù)據(jù)庫的作?是能夠為軟件系統(tǒng)提供后臺數(shù)據(jù)存儲與運算。許多應?系統(tǒng)需要依賴數(shù)據(jù)庫提供數(shù)據(jù)服務，尤其是?些信息管理系統(tǒng)，則更是以數(shù)據(jù)庫為中?進?部署。與?般數(shù)據(jù)?件?較，數(shù)據(jù)庫具有以下??的優(yōu)越性：

（1）數(shù)據(jù)庫具有特殊的數(shù)據(jù)存儲結構，例如，關系型數(shù)據(jù)庫中的表結構，更加適宜對數(shù)據(jù)進?有效的組織、存儲和檢索。

（2）數(shù)據(jù)庫具有更加完善的數(shù)據(jù)完整性約束機制，例如，可以通過設置和字段相關的主鍵、外鍵，從?建?起數(shù)據(jù)表集之間的關聯(lián)；可以設置對數(shù)據(jù)字段、記錄的檢驗規(guī)則，以限制數(shù)據(jù)存儲范圍。

（3）數(shù)據(jù)庫能夠實現(xiàn)數(shù)據(jù)存儲結構與數(shù)據(jù)表現(xiàn)形式的有效隔離，例如，可以通過數(shù)據(jù)視圖?獲得對數(shù)據(jù)表集更加有效的應?組合。本節(jié)將簡要介紹數(shù)據(jù)庫的結構設計，并將從邏輯結構設計和物理結構設計這兩個??分別給予說明。

1.邏輯結構設計

需求分析中已建?了有關數(shù)據(jù)庫的數(shù)據(jù)關系模型。但是，數(shù)據(jù)關系模型是基于對?戶應?域的分析?構造的，是?個有關現(xiàn)實數(shù)據(jù)環(huán)境的數(shù)據(jù)庫概念模型。顯然，這種接近于現(xiàn)實世界的概念模型與計算機世界之間的距離太?了，不能夠直接向數(shù)據(jù)庫實現(xiàn)過渡。因此，為了?便數(shù)據(jù)庫的創(chuàng)建，需要將數(shù)據(jù)庫概念模型進?轉換，建??種更加接近計算機世界的數(shù)據(jù)庫模型。概要設計中需要建?的有關數(shù)據(jù)庫的邏輯結構，就是?種與計算機世界更加接近的數(shù)據(jù)模型，它提供了有關數(shù)據(jù)庫內部構造的更加接近于實際存儲的邏輯描述，因此能夠為在某種特定的數(shù)據(jù)庫管理系統(tǒng)上進?數(shù)據(jù)庫物理創(chuàng)建提供便利。

（1）設計數(shù)據(jù)庫

在關系型數(shù)據(jù)庫中，數(shù)據(jù)是以數(shù)據(jù)表為單位實現(xiàn)存儲的。因此，數(shù)據(jù)庫邏輯結構設計?先需要確定的就是數(shù)據(jù)庫中的諸多數(shù)據(jù)表。

可以按照以下規(guī)則從數(shù)據(jù)關系模型中映射出數(shù)據(jù)庫中的數(shù)據(jù)表來。

a.數(shù)據(jù)關系模型中的每?個實體應該映射為數(shù)據(jù)庫邏輯結構中的?個數(shù)據(jù)表。另外，實體的屬性對應于數(shù)據(jù)表的字段，實體的碼對應于數(shù)據(jù)表的主鍵。

b.數(shù)據(jù)關系模型中的每?n:m關系也應該映射為數(shù)據(jù)庫邏輯結構中的?個數(shù)據(jù)表。另外，與該關系相連的各實體的碼以及關系本?的屬性，應該映射為數(shù)據(jù)表的字段；?與該關系相連的各實體的碼，則需要組合起來作為關系數(shù)據(jù)表的主鍵。

c.數(shù)據(jù)關系模型中的每?1:n關系可以映射為?個獨?的數(shù)據(jù)表（映射規(guī)則類n:m關系）。但在更多情況下，這1:n關系則是與它n端對應的實體組合起來映射為?個數(shù)據(jù)表。1:n關系是n端對應實體合并組成數(shù)據(jù)表時，組合數(shù)據(jù)表的字段中需要含1端實體的碼屬性。

d.數(shù)據(jù)關系模型中的每?1:1關系可以映射為?個獨?的數(shù)據(jù)表，也可以與跟它相連的任意?端或兩端的實體合并組成數(shù)據(jù)表。實際上，兩個依

靠1:1關系聯(lián)系的數(shù)據(jù)表可以設置相同的主鍵，為了減少數(shù)據(jù)庫中的數(shù)據(jù)表的個數(shù)，往往將它們合并為?個數(shù)據(jù)表。合并?法是將其中?個數(shù)據(jù)表的全部字段加?到另?個數(shù)據(jù)表中，然后去掉其中意義相同的字段（包括意義相同但名稱不同的字段）。圖5-37是?個?于描述教師、課程、學?三者之間關系的數(shù)據(jù)關系模型圖?？梢园凑丈鲜鲆?guī)則對這個數(shù)據(jù)關系模型進?映射，由此可以產(chǎn)?出以下數(shù)據(jù)表結構：教師（教師編號，姓名，性別，職稱，學歷）課程（課號，課名，計劃課時，學分）學?（學號，姓名，性別，專業(yè)，班級）講授（教師編號，課號，實際課時）學習（學號，課號，成績）

（2）規(guī)范數(shù)據(jù)表

從數(shù)據(jù)關系模型映射出來的數(shù)據(jù)表是直接建?在?戶應?域基礎上的數(shù)據(jù)表。實際上，同?個數(shù)據(jù)關系模型可以有許多種不同的數(shù)據(jù)表組合。為了使數(shù)據(jù)庫邏輯結構更加科學合理，設計過程中，?般還需要按照關系數(shù)據(jù)庫規(guī)范原理對數(shù)據(jù)表進?規(guī)范化處理，由此可消除或減少數(shù)據(jù)表中存在的不合理現(xiàn)象，例如數(shù)據(jù)存儲冗余、數(shù)據(jù)更新異常。關系數(shù)據(jù)庫規(guī)范原理是基于數(shù)據(jù)冗余程度提出的，包含第?范式（1NF）、第?范式（2NF）、第三范式（3NF）、BC范式（BCNF）、第四范式（4NF）和第五范式（5NF）。其中，第?范式規(guī)范化程度最低，數(shù)據(jù)表內部多余聯(lián)系最多，數(shù)據(jù)冗余最?；第五范式規(guī)范化程度最?，數(shù)據(jù)表內部?乎沒有多余的聯(lián)系，數(shù)據(jù)冗余最?。顯然，通過提?數(shù)據(jù)表范式級別可以降低數(shù)據(jù)表中的數(shù)據(jù)冗余，并可減少由于數(shù)據(jù)冗余造成的數(shù)據(jù)更新異常。但是，為了提?數(shù)據(jù)表范式級別，就需要清除數(shù)據(jù)表內部的多余聯(lián)系，這就需要對數(shù)據(jù)表進?分解。值得注意的是，對數(shù)據(jù)表的分解?都會使對數(shù)據(jù)的查詢操作復雜起來（例如多表聯(lián)接操作），由此會降低數(shù)據(jù)查詢性能。在數(shù)據(jù)庫實際應?中，為了既能使數(shù)據(jù)冗余與數(shù)據(jù)更新異常現(xiàn)象有所減少，?能使數(shù)據(jù)查詢性能不會出現(xiàn)顯著下降，?多選?第三范式作為設計優(yōu)化依據(jù)。

下?是對數(shù)據(jù)表中第?范式、第?范式和第三范式的描述。

a.第?范式數(shù)據(jù)表中的每?個字段值都必須是不可再進?分割的原?數(shù)據(jù)。

b.第?范式滿?第?范式條件，?且已經(jīng)消除數(shù)據(jù)表中可能存在的?關鍵字段對關鍵字段集中個別字段的部分依賴關系。也就是說，每?個?關鍵字段都只能由整個關鍵字段集決定，?不能由關鍵字段集中的個別字段決定。

c.第三范式滿?第?范式條件，?且已經(jīng)消除數(shù)據(jù)表中可能存在的?關鍵字段之間的傳遞依賴關系。也就是說，每?個?關鍵字段都只能由關鍵字段集決定，?不能由?關鍵字段集決定。?般情況下，如果數(shù)據(jù)表中的數(shù)據(jù)需要經(jīng)常更改，這個數(shù)據(jù)表可以選?第三范式，甚BC范式。但如果數(shù)據(jù)表中的數(shù)據(jù)不會更改或很少更改，卻經(jīng)常需要查詢，并且要求有較?的查詢性能，則可以選擇第?范式，甚?第?范式。

（3）關聯(lián)數(shù)據(jù)表

關聯(lián)數(shù)據(jù)表就是將數(shù)據(jù)關系模型中數(shù)據(jù)實體之間的關系在數(shù)據(jù)庫邏輯結構中明確體現(xiàn)出來，它們將作為建?數(shù)據(jù)表之間參照完整性規(guī)則的依據(jù)。圖5-38是數(shù)據(jù)庫的邏輯模型圖，其中的連線表?了數(shù)據(jù)表之間的關聯(lián)，連線帶箭頭?端為主表，另?端為從表。其中，標PK表?主表中的主鍵，標FK表?從表中的外鍵。主表與從表的關聯(lián)就建?在主表的主鍵字段集和從表的外鍵字段集之間。

（4）設計數(shù)據(jù)視圖

數(shù)據(jù)視圖也稱做虛表，原因在于數(shù)據(jù)視圖與數(shù)據(jù)表?樣，都可以將數(shù)據(jù)以記錄集合形式表現(xiàn)出來。但是，數(shù)據(jù)視圖是?向系統(tǒng)前端應?的不同?戶的局部邏輯層。因此，它與?向系統(tǒng)后臺全局數(shù)據(jù)存儲的數(shù)據(jù)表也就有著許多不同之處。?般說來，數(shù)據(jù)表具有相對穩(wěn)定的存