管理信息系統設計第五章管理信息系統設計知識目標了解結構化設計的基本概念和方法。了解面向對象設計的基本概念。了解系統體系結構設計。掌握結構化系統設計的總體設計與詳細設計。掌握面向對象設計的過程與原則。技能目標在了解結構化設計概念與方法的基礎上，初步具備利用結構化設計方法設計相關軟件的能力；在熟知的基礎上，能夠利用面向對象設計方法對實際問題進行抽象并且構造出相應的數據模型。第五章管理信息系統設計結構化系統設計面向對象系統設計系統設計概述系統總體設計系統詳細設計系統設計說明書面向對象設計概述信息系統體系結構設計軟件類設計面向對象設計原則第五章管理信息系統設計第一節結構化系統設計概述一、系統設計概述（一）系統設計的概念系統設計又稱為物理設計，是開發管理信息系統的第二階段。系統設計通?？梢苑譃榭傮w設計和詳細設計?？傮w設計的任務是設計系統的框架和概貌，并向用戶單位和領導部門作詳細報告以獲得認可；詳細設計是在總體設計的基礎上進行的，這兩部分工作是互相聯系的，需要交叉進行。系統設計是開發人員進行的工作，他們將系統分析階段得到的目標系統的邏輯模型轉換為目標系統的物理模型。該階段得到的工作成果—系統設計說明書是下一個階段需要實施的工作依據。第五章管理信息系統設計第一節結構化系統設計概述一、系統設計概述（二）系統設計的基本原則嚴格遵循系統分析報告所提供的文檔資料，不能任意更改系統的功能和性能要求。權衡系統的投資和效益比例保證系統的效率和質量。體現系統的可擴展性和可適應性。合理運用先進和成熟的技術，既要考慮系統的先進性又要避免更大的風險。保證系統的安全性。產生完備的系統設計說明書。第五章管理信息系統設計第一節結構化系統設計概述一、系統設計概述（三）系統設計的目標系統設計的目標是否達標可以從以下六個方面來衡量1.系統的功能是否解決了用戶希望解決的問題，是否有較強的數據校驗功能，能否完成所需要的運算，能否提供符合用戶需要信息輸出等2.系統的效率影響系統效率的因素很多，包括系統的硬件及其組織結構、人機接口的合理性、計算機處理過程的速度等。第五章管理信息系統設計第一節結構化系統設計概述一、系統設計概述（三）系統設計的目標系統設計的目標是否達標可以從以下六個方面來衡量3.系統的可靠性是指系統在運行過程中抵御各種干擾、保證系統正常工作的能力，包括檢查錯誤、糾正錯誤的能力和系統一旦發生故障后重新恢復、重新啟動的能力。4.系統的工作質量指系統提供信息的準確程度、使用的方便性、輸出表格的實用性和清晰性等。第五章管理信息系統設計第一節結構化系統設計概述一、系統設計概述（三）系統設計的目標系統設計的目標是否達標可以從以下六個方面來衡量5.系統的可變更性是指修改和維護系統的難易程度。6.系統的經濟性指系統的收益和支出之比。系統設計概述系統設計系統總體設計系統詳細設計系統模塊結構設計計算機物理系統的配置方案設計代碼設計數據庫設計界面設計處理流程設計編寫系統設計說明書（四）系統設計的內容輸入輸出設計模塊結構圖、模塊說明書其他詳細設計的內容第五章管理信息系統設計第一節結構化系統設計概述一、系統設計概述（四）系統設計的內容→總體設計（1）系統模塊結構設計：它的主要任務是劃分子系統，然后確定子系統的模塊結構，并畫出模塊結構圖。在這個過程中必須考慮以下問題：如何將一個系統劃分成多個子系統。每個子系統如何劃分成多個模塊。如何確定子系統之間、模塊之間傳送的數據及其調用關系。如何評價并改進模塊結構的質量。第五章管理信息系統設計第一節結構化系統設計概述一、系統設計概述（四）系統設計的內容→總體設計（2）計算機物理系統的配置方案設計：要解決計算機軟、硬件系統的配置，通信網絡系統的配置，機房設備的配置等問題。第五章管理信息系統設計第一節結構化系統設計概述一、系統設計概述（五）系統劃分的一般原則（1）子系統要具有相對獨立性

子系統的劃分必須使得子系統的內部功能、信息等各方面的凝聚性較好。在實際中我們都希望每個子系統或模塊相對獨立，盡量減少各種不必要的數據、調用和控制聯系。并將聯系比較密切、功能近似的模塊相對集中，這樣對于以后的搜索、查詢、調試、調用都比較方便。

（2）子系統劃分的結果應使數據冗余最小

如果我們忽視這個問題，則可能引起相關的功能數據分布在各個不同的子系統中，大量的原始數據需要調用，大量的中間結果需要保存和傳遞，大量計算工作將要重復進行。從而使得程序結構紊亂，數據冗余，不但給軟件編制工作帶來很大的困難，而且系統的工作效率也大大降低了。第五章管理信息系統設計第一節結構化系統設計概述一、系統設計概述（五）系統劃分的一般原則（3）要使子系統之間數據的依賴性盡量小

子系統之間的聯系要盡量減少，接口簡單、明確。一個內部聯系強的子系統對外部的聯系必然是相對很少。所以劃分時應將聯系較多的都劃入子系統內部。這樣劃分的子系統，將來調試、維護、運行都是非常方便的。（4）子系統的設置應考慮今后管理發展的需要

子系統的設置光靠上述系統分析的結果是不夠的，因為現存的系統由于這樣或那樣的原因，很可能都沒有考慮到一些高層次管理決策的要求。為了適應現代管理的發展，對于老系統的這些缺陷，在新系統的研制過程中應設法將它補上。只有這樣才能使系統實現以后不但能夠更準確、更合理地完成現存系統的業務，而且可以支持更高層次、更深一步的管理決策。第五章管理信息系統設計第一節結構化系統設計概述一、系統設計概述（五）系統劃分的一般原則（5）子系統的劃分應便于系統分階段實現信息系統的開發是一項較大的工程，它的實現一般都要分期分步進行。所以子系統的劃分應該考慮到這種要求，適應這種分期分步的實施。另外，子系統的劃分還必須兼顧組織機構的要求（但又不能完全依賴于組織，因為目前正在進行體制改革，組織結構相對來說是不穩定的），以便系統實現后能夠符合現有的情況和人們的習慣，更好地運行。返回本節目錄系統分析系統實施系統設計根據系統分析階段所確定的新系統的邏輯模型，綜合考慮各種約束，利用合理的技術手段和方法，提出一個能在計算機上實現的新系統的物理模型，解決系統“怎樣做”的問題。第五章管理信息系統設計第一節結構化系統設計概述二、系統總體第五章管理信息系統設計第一節結構化系統設計概述二、系統總體設計（一）系統總體設計的任務

根據系統分析的邏輯模型設計應用軟件系統的物理結構。系統的物理結構必須符合邏輯模型，具備邏輯模型所規定的信息處理功能，這是物理設計的基本要求。

系統應具有可修改性，即易讀，易于進行差錯、改錯，可以根據環境的變化和用戶的要求進行各種改變和改進。

（二）系統總體設計的方法結構化設計方法。第五章管理信息系統設計第一節結構化系統設計概述二、系統總體設計（三）結構化設計的基本思想

結構化設計方法的特點：（1）模塊結構相對獨立、功能單一。（2）具有“塊內聯系大、塊間聯系小”的模塊性能標準（3）采用模塊結構圖的描述方式。結構化設計的要點：（1）模塊化。（2）自頂向下、逐步求精。（3）信息隱藏。第五章管理信息系統設計第一節結構化系統設計概述二、系統總體設計（四）結構化設計的評估準則

從用戶的角度來看，一個高質量的軟件至少應具備兩個特點。易于實施和測試；易于修改和維護。從軟件結構的角度來看，一個是耦合，另一個是內聚。

模塊的獨立性不同模塊間的相互聯系應盡可能的少，一個模塊應盡可能的具有完整單一的功能耦合度內聚性模塊間的聯系程度模塊內的聯系程度第五章管理信息系統設計第一節結構化系統設計概述二、系統總體設計耦合度內容耦合一個模塊直接修改另一個模塊的數據公共耦合控制耦合數據耦合標記耦合兩個以上模塊共同引用一個全局數據項一個模塊通過信號控制另一個模塊模塊間通過參數等方式傳遞數據下級模塊使用上級模塊傳送的整體數據記錄中的部分數據項第五章管理信息系統設計內聚性偶然內聚模塊內各處理間無有意義聯系邏輯內聚暫時內聚過程內聚通信內聚模塊內是邏輯功能相似的處理處理動作與時間有關，與問題無關功能各不相關但具有前后關系的處理操作或生成同一組數據的處理順序內聚功能內聚具有順序關系的功能相關的處理實現某一功能所必需的全部處理第五章管理信息系統設計模塊劃分的原則降低模塊間耦合提高模塊內聚性第五章管理信息系統設計模塊劃分完成了，是不是模塊結構設計就做完了？表示模塊間的關系模塊結構圖第五章管理信息系統設計（五）系統總體設計-控制結構圖的繪制模塊結構圖圖例A矩形表示模塊，矩形中寫模塊名稱箭頭表示模塊間的調用關系小箭頭表示表示模塊間在調用過程中相互傳遞的信息作數據用的信息作控制用的信息模塊結構圖圖例輔助符號選擇調用循環調用（五）系統總體設計-控制結構圖的繪制模塊結構圖示例（五）系統總體設計-控制結構圖的繪制模塊結構圖注意事項模塊結構圖著重反映模塊間的隸屬關系（即調用關系與層次關系），只考慮模塊功能、相互關系，而不涉及模塊內部細節模塊結構圖不表示模塊間調用次序與時間關系，即使大多數人有從左向右繪圖的習慣（五）系統總體設計-控制結構圖的繪制模塊結構圖轉換數據流程圖步驟一確定輸入、變換、輸出部分步驟二設計模塊結構的頂層（總控模塊）與第一層（輸入、變換、輸出模塊）步驟三設計下層模塊（五）系統總體設計-控制結構圖的繪制數據流程圖轉換模塊結構圖示例學生選課系統數據流程圖（五）系統總體設計-控制結構圖的繪制數據流程圖轉換模塊結構圖示例選課主模塊輸入身份信息選課處理輸出選課信息輸入密碼驗證密碼課程查詢選課登記顯示課表打印課表學號密碼學號驗證信息選課信息選課信息課表課表課表課表課表學號學號密碼驗證信息學號（五）系統總體設計-控制結構圖的繪制控制結構圖（模塊結構圖）的基本繪制原則如下：（1）每個模塊有自身的任務，只有接受到上級模塊的調用命令時才能執行。（2）模塊之間的通信只限于其直接上、下級模塊，人和模塊都不能直接與其他上下級模塊或同級模塊發生通信聯系。（3）若有某模塊要與非直接上、下級的其他模塊發生通信聯系，必須通過其上級模塊進行傳遞。（4）模塊調用順序為自上而下。在控制結構圖中，把一個系統分解為若干模塊，實質上是把一件比較抽象、物理內容不大確定的任務分解為若干件比較具體的、物理內容比較確定的任務。（五）系統總體設計-控制結構圖的繪制控制結構圖（模塊結構圖）的基本繪制原則如下：

控制結構圖既可以反映系統的整體結構，又能反映系統的細節，既能準確反映各組成部分（各模塊）及它們之間的聯系。而DFD中流入“處理功能”的數據流映射為輸入模塊的數據流，DFD中流出“處理功能”的數據流映射成從“模塊”中輸出的數據流。（五）系統總體設計-控制結構圖的繪制分解采用的方式

（1）以轉換為中心結構的分解：如果待分解的模塊是一個數據凝聚的模塊，即內部包含若干順序執行且對某些數據進行轉換處理，稱為已轉換為中心的結構。這種模塊可分解為輸入-處理-輸出-三大部分。

（2）以業務為中心結構的分解：待分解的模塊要處理幾項邏輯上相似的業務，即它是一個邏輯內聚的模塊?？梢詫⑦@種模塊分解為一個檢查業務類型的模塊和一個調度模塊，根據不同的業務類型，調度模塊調用不同的下層模塊，進行不同的處理。

以上兩種分解方式常常要混合使用，已達到模塊內聚程度高、模塊之間獨立性強、易于修改的目的。（五）系統總體設計-控制結構圖的繪制返回本節目錄第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計（一）代碼設計（二）輸出設計（三）輸入設計（四）處理過程設計（五）數據存儲設計（六）用戶界面設計返回本節目錄第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計（一）代碼設計代碼也叫信息編碼。是作為事物（實體）唯一標志的、一組有序字符組合，用來表示事物名稱、屬性和狀態等的符號。它必須便于計算機和人識別、處理。在管理信息系統中，代碼是人和機器的共同語言，是系統進行信息分類、校對、統計和檢索的依據。代碼設計就是要設計出一套能為系統各部門公用的、優化的代碼系統，這是實現計算機管理的一個前提條件。第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計（一）代碼設計1.代碼的重要性代碼的重要性表現在以下幾個方面：（1）可以唯一地標記一個分類對象（實體）。（2）便于儲存和檢索，節省儲存空間。（3）使標準化的表達數據，簡化了處理程序，提高了處理效率。2.代碼設計的原則（1）唯一性：是區別系統中每個實體或屬性的唯一標志。（2）簡單性：盡量壓縮代碼長度，可降低出錯機會。（3）易識別性：為便于記憶、減少出錯，代碼應當邏輯性強，表已明確。（4）可擴充性：不需要變動原代碼體系，可直接追加新代碼，以適應系統發展。（5）合理性：必須在邏輯上滿足應用需要，在結構上與處理方法相一致。（6）規范性：盡可能采用現有國標、部標編碼，統一結構。第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計3.代碼種類代碼的種類是指代碼符號的表現形式，進行代碼設計時可選擇一種或幾種代碼類型組合。一般可按文字或功能給代碼進行分類。按文字種類可以分為數字代碼、字母代碼和字母數字混合碼。按功能則可以分為以下幾類：（1）順序碼，也叫序列碼，用連續數字作為每個實體的標志，編碼順序可以是實體出現的先后或實體名的字母順序等。其優點是簡單、易處理、易擴充、用途廣；缺點是沒有邏輯含義，不能表示信息特征，無法插入數據，刪除數據將造成空碼。第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計3.代碼種類（2）重復性，采用與原來手工系統相同的編碼。其優點是容易被原系統人員接受，易實現，便于推廣；缺點是不能任意更改。（3）成組碼，是最常用的一種編碼，它將代碼分為幾段（組），每段都由連續數字組成，表示一種含義。其優點是簡單、方便，能夠反映出分類體系，易校對，易處理；缺點是位數多，不便記憶，必須為每段預留編碼，否則不易擴充。（4）表意碼，是將表示實體特征的文字、數字或幾號直接作為編碼。其優點是可以直接明白編碼含義、易理解、易記憶；缺點是編碼長度位數可變，給分類、處理帶來不變。例如，網站代碼就是表意碼。第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計3.代碼種類

（5）專用碼，是具有特殊用途的編碼，如漢字國標碼、五筆字型編碼、自然碼、ASCII代碼等。

（6）組合碼，也叫合成碼、復雜碼，它由若干種簡單編碼組合而成，使用十分普遍。其優點是容易分類，容易增加編碼層數，可以從不同角度識別編碼，容易實現多種分類統計；缺點是編碼位數和數據項個數較多。

4.代碼校驗

校驗碼是按事先規定好的算法計算出來，將它附加到代碼本體上以后，成為代碼的一個組成部分。當代碼輸入到計算機以后，系統將會按規定好的算法驗證，從而檢測代碼的正確性。第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計4.代碼校驗（1）校驗值的生成過程。1）第一步，對原代碼中的每一位加權求和S。N位代碼為：C1，C2，C3，···，Cn；權因子為：P1，P2，P3，···，Pn；加權和為：S=C1×P1+C2×P2+C3×P3+···+Cn×Pn。其中，全因子可任意選取，以提高錯誤發生率為基礎。常用的有：全取1；幾何級數20,21,22···；擺動列數1,2,1,2···；等等。2）求余數R，用加權和S除以模數M（常用的模數為10和11）可得余數R，即S/M=Q······R（Q為商數）。3）選擇校驗值，可選用下述方法中的一種獲得校驗值：余數R直接作為校驗值；把模數M和R只差（即M-R）作為校驗值；取R的若干位作為校驗值。把獲得的校驗值放在原代碼的最后作為整個代碼的組成部分。（2）用校驗值檢查代碼的過程。此過程是上述生成過程的逆過程，這里不再解釋。5代碼設計的步驟（1）確定代碼對象。（2）考查是否已有標準代碼。如果國家標局、某個部門對某些事物已規定了標準代碼，那么應遵循這些標準代碼。如果沒有標準代碼，那么在進行代碼設計時要參考國際標準化組織、其他國家、其他部門、其他單位的編碼標準，設計出便于今后標準化的代碼。（3）根據代碼的使用范圍、使用時間和實際情況選擇代碼的種類與類型。（4）考慮檢錯功能。（5）編寫代碼表。代碼編寫好后，要編制代碼表，作詳細說明，通知有關部門，組織學習，一邊正確使用。居民身份證編碼規則ABCDEFYYYYMMDDXXXR地址碼（ABCDEF）：表示編碼對象常住戶口所在縣(市、旗、區)的行政區劃代碼，按【GB/T2260】的規定執行。出生日期碼（YYYYMMDD）：表示編碼對象出生的年、月、日，按【GB/T7408】的規定執行。順序碼（XXX）：表示在同一地址碼所標識的區域范圍內，對同年、同月、同日出生的人編定的順序碼，順序碼的奇數分配給男性，偶數分配給女性。校驗碼（R），一位數字，通過前17位數字參照【ISO7064:1983.MOD11-2】規則計算得出。5代碼校驗的功能：核對輸入代碼是否正確。校驗位可以發現的錯誤 錯字 1234 1224 錯位 1234 1243代碼校驗方法 建立代碼字典 如公安部人口身份信息數據庫 設置校驗位 如身份證號第18位數字5.3.1代碼設計-代碼校驗131082199905010277910584216379105842XXXXXXXXXXXXXXXXX‖‖‖‖‖‖‖‖‖‖‖‖‖‖‖‖‖727100648295427045050814+=+++++++++++++++?R012345678910校驗值0123456789XS=280M=11280/11=25…5=R返回本條目錄5第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計（二）輸出設計輸出設計主要考慮輸出要求的確定、輸出方式的選擇和輸出格式的設計。輸出設備和介質也要考慮在內。

（二）輸出設計

1.輸出要求的確定在確定一個系統究竟應輸出什么信息時，應按照下列步驟加以調查和分析：（1）詳細分析現行系統的輸出報表和內容，找出哪些報表是真正需要的，哪些是重復的或可以合并的，各分報表的輸出周期等。（2）參照與用戶同類型企業或部門的情況，借鑒業務性質類似的其他MIS的經驗。（3）與用戶單位的實際業務人員討論。第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計（二）輸出設計

2.輸出方式的選擇目前，我國MIS主要使用的輸出方式是屏幕顯示和打印機打印。磁盤、磁帶、移動硬盤、U盤則往往作為一種保存數據的手段。輸出介質主要是各種規格的打印紙，包括專用的和通用的。第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計3.輸出格式的設計

對輸出格式設計的基本要求如下：（1）規格標準化，文字和術語統一。（2）使用方便，符合用戶的習慣。（3）美觀大方，界面漂亮。（4）便于計算機實現。（5）能適當考慮系統發展的需要。

設計屏幕輸出格式時，除了合理安排數據項的顯示位置外，還應注意適當的顏色搭配，美觀的屏幕輸出格式會使人賞心悅目，容易獲得用戶好感。

設計紙質報表的格式時，要先了解打印機的特性。為便于編寫輸出程序，設計輸出格式時，最好先在方格紙上擬出草圖。三、系統詳細設計→輸出設計返回本條目錄（三）輸入設計

輸入設計的目的是：在保證輸入信息正確性和滿足輸出需求的前提下，盡量做到輸入方法簡便、迅速、經濟。1.輸入設計的原則：（1）輸入量應保持在能滿足處理要求的最低限度。（2）杜絕重復輸入，特別是在數據能共享的大系統中，一定要避免重復輸入。（3）輸入數據的匯集和輸入操作應盡量簡便易行，減少錯誤的發生。（4）輸入數據應盡早處理成所需要的形式，用這種形式進行記錄，以減少或避免由一種介質轉換到另一種介質時可能產生的錯誤。第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計（三）輸入設計

2.輸入數據的獲得：原始的賬單、票據、憑證、臺賬、賬簿等。3.輸入格式的設計輸入格式應該針對輸入設備的特點進行設計。若選用鍵盤方式人機交互輸入數據，則輸入格式的編排應盡量做到計算機屏幕顯示方式與單據格式一致。輸入數據的形式一般可采用“填表式”，有用戶逐項輸入數據，輸入完畢后系統應具有要求“確認”輸入數據是否正確無誤的功能。第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計（三）輸入設計

4.輸入數據的校驗：

常用的校驗方法有以下兩種：

（1）重復輸入校驗。（2）程序校驗法：根據輸入數據的特性，編寫相應的校驗程序對輸入的數據進行檢查。第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計返回本條目錄（四）處理過程設計

第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計在獲得模塊結構圖以后，就可以設計各模塊的處理過程，為程序員編寫程序做準備，是編程的依據。處理過程設計（模塊詳細設計）通常是在IPO(Input-Process-Output)圖上進行，是用來表述每個模塊的輸入，輸出和數據加工的重要工具。常用系統的IPO圖的結構如下圖表示（四）處理過程設計

第五章管理信息系統設計模塊詳細設計時除了要滿足某個具體模塊的功能、輸入和輸出的基本要求以外，還應考慮以下幾個方面的問題：（1）模塊間的接口要符合通信的要求。（2）考慮將來實現時所有計算機語言的特點。（3）考慮數據處理的特點。（4）估計計算機執行時間不能超出要求。（5）考慮程序運行所占用的存儲空間。（6）使程序調試跟蹤方便。（7）估計編程和上機調試的工作量。返回本條目錄（五）數據存儲設計

第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計對數據的存儲和管理有文件、數據庫兩種方式1.文件設計文件是按一定的組織方式存放在存儲介質上的同類記錄的集合。文件設計就是根據文件的使用要求、處理方式、存儲量、數據的活動性以及硬件設備的條件等，合理地確定文件類別，選擇文件存儲介質，決定文件的組織方式和存取方法，估算文件容量等。文件由記錄組成，所以設計文件主要是設計文件記錄的格式，詳見文件記錄的格式實例（五）數據存儲設計文件設計記錄文件名：主文件應用：工資子系統序號123456數據項名職工代碼職工姓名部門基本工資附加工資扣房費變量名DMXMBMJBGZFJGZFF類型CCCNNN寬度482777小數位數222輸入到：輸出自：設計人員簽名

設計日期

。

（五）數據存儲設計文件數據的具體內容如下：（1）對數據字典描述的數據存儲情況進行分析，確定需要作為文件存儲的內容，區分固定數據、流動數據和共享數據，決定文件類型。（2）決定需要建立的文件及其用途和內容，并為每個文件選取文件名。（3）選擇文件的存儲介質和組織形式。（4）根據數據結構設計記錄格式。（5）根據記錄長度，記錄個數和文件總數估算出整個系統的數據存儲容量。2.數據庫設計

數據厙設計是在選定的數據庫管理系統基礎上建立數據庫的過程。數據庫設計除用戶需求分析外，還包括概念結構設計、邏輯結構設計和物理結構設計等三個階段。由于數據庫系統已形成一門獨立的學科，所以，當我們把數據庫設計原理應用到MIS開發中時，數據庫設計的幾個步驟就與系統開發的各個階段相對應，且融為一體，它們的對應關系如下圖所示。

2.數據庫設計

（1）數據厙設計的要求：數據厙設計的目標是建立一個合適的數據模型，這個數據模型應符合以下條件：滿足用戶要求滿足某個數據庫管理系統的要求。具有較高的范式：數據完整性好、效益高，便于理解和維護，沒有數據沖突。（2）數據庫數據步驟：可以分為概念結構設計、邏輯結構設計和物理結構數據三個階段。概念結構設計應在系統分析階段進行，任務是根據用戶需求設計數據庫的概念數據模型(簡稱概念模型)。概念模型是從用戶角度看到的數據庫，它可用前面章節中介紹的E-R模型表示。數據庫的邏輯結構設計邏輯結構設計是將概念結構設計階段完成的概念模型轉換成能被選定的數據庫管理系統(DBMS)支持的數據模型。數據模型可以由實體聯系模型轉換而來。E-R模型轉換為關系數據模型的規則：每一實體集對應于一個關系模式，實體名作為關系名，實體的屬性作為對應關系的屬性。實體間的聯系一般對應一個關系，聯系名作為對應的關系名，不帶有屬性的聯系可以去掉。實體和聯系中關鍵字對應的屬性在關系模式中仍作為關鍵字。2.數據庫設計

概念結構的轉換舉例：

實體聯系圖

2.數據庫設計

根據規則，轉換成對應的關系數據模型:①供方單位(單位號、單位名、地址、聯系人、郵政編碼)。②物資(代碼、名稱、規格、備注)③庫存(入庫號、日期、貨位、數量)④合同(合同號、數量、金額、備注)⑤結算(編號、用途、金額、經手人)⑥購進(入庫號、編號、數量、金額)⑦付款(編號、合同號、數量、金額)⑧訂貨(代碼、單位號、合同號、數量、單價)2.數據庫設計

概念結構的轉換舉例：

數據庫的物理結構設計

物理結構設計：為一個確定的邏輯數據模型選擇一個最適合應用要求的物理結構的過程。數據庫在物理設備上的存儲結構和存取方法稱為數據庫的物理數據模型。數據庫數據最后階段是確定數據庫的物理數據模型。2.數據庫設計

返回本條目錄（六）用戶界面設計

第五章管理信息系統設計第一節結構化系統設計概述三、系統詳細設計用戶界面主要有菜單式、填表式、選擇問答式和按鈕式四種形式菜單式目前常用的菜單設計方法有以下幾種：一般菜單。下拉菜單?？戽I菜單。返回本條目錄返回本節目錄第五章管理信息系統設計第一節結構化系統設計概述四、系統設計說明書系統設計說明書包括以下幾個方面的內容：引言引言主要說明項目的背景、工作條件及約束、引用資料和專門術語。2.系統總體技術方案系統總體技術方案是系統說明書中最主要的部分，包括以下幾個方面的內容：（1）模塊設計：用結構圖表示系統模塊層次結構，說明主要模塊的名稱、功能。（2）代碼設計：說明所用代碼的種類、功能、代碼表?？傮w方案包括內容：（3）輸入設計：說明輸入的項目、主要功能、輸入要求、輸入的承擔著、輸入校驗方法等。（4）輸出設計：說明輸出的項目、主要功能、輸出的接受者、輸出的數據類型與設備、介質、數值范圍、精度要求等。（5）數據庫設計：說明數據設計的目標、主要功能要求、需求性能規定、運行環境要求、邏輯設備方案、物理設計方案。（6）網絡設計：說明系統的網絡結構、功能設計。（7）安全保密設計。（8）實施方案說明。系統設計說明書還要說明實施的計劃安排，給出各項工作（包括文件編制、用戶培訓）的預定日期和完成日期，規定各項工作的先后次序即工作完成的標志。可以用PERT圖或甘特圖表示。在經費預算中，要逐項列出本開發項目實施需要的各項經費（包括辦公費、差旅費、機時費、資料費、設備租金等）。出用戶、系統研制人員外，還應邀請有關專家人員、管理人員審批實施方案，并將評審意見及審批人員名單附于系統說明書之后，經批準后，實施方案方可生效。返回本節目錄

面向對象設計（OOD，Object-OrientedDesign）是面向對象分析到實現的一個橋梁。面向對象分析是將用戶需求經過分析后，建立問題域精確模型的過程；而面向對象設計則根據面向對象分析得到的需求模型，建立求解域模型的過程。即分析必須搞清楚系統“做什么”，而設計必須搞清楚系統“怎么做”，從分析到設計不是傳統方法的轉換，而是平滑（無縫）過渡，而求解域模型是系統實現的依據。

第五章管理信息系統設計第二節面向對象設計第五章管理信息系統設計第二節面向對象設計一、面向對象設計概述面向對象設計是在面向對象分析的基礎上增加實現的細節來完成的。（一）面向對象設計模型面向對象設計的任務可用Coad和Yourdon提出的面向對象設計模型表示，該模型由四個部分和五個層次組成，其中四個部分是問題領域、人機交互、任務管理、和數據管理；五個層次是主題層、對象層、結構層、屬性層、和服務層。問題領域部分是針對業務領域進行的總體設計，它包括完成目標系統主要功能的對象。問題領域設計以面向對象分析為基礎，通過擴展和調整，為實現有關功能所需的類、對象等提供實現途徑。人機交互部分給出實現人機交互需要的對象。其主要工作是進一步熟悉用戶，分析用戶工作流程與習慣，設計命令系統，設計用戶界面細節，設計用戶界面專用類等。此外，也可以利用快速原型技術對人機交互部件的設計進行驗證。（一）面向對象設計模型任務管理主要包括任務的選擇和調整。所謂任務是進程的別稱，是執行一系列活動的一段程序。當系統中有許多并發行為時，需要依照各個行為的協調和通信關系，劃分各種作為，以達到簡化并發行為的設計和編碼的目的。任務關系部分的工作包括：識別事件驅動任務；識別時鐘驅動任務，識別優先任務和關鍵任務；識別任務之間的協調者；對各個任務進行審評，保證它能夠滿足選擇任務的過程標準；定義各個任務、說明它是什么任務、任務之間如何協調工作、如何通信。數據管理部分主要是定義專用對象，它將目標軟件系統中有關開發平臺的數據存取操作與其他功能分開，以提高對象的獨立性。數據存取的主要功能包括數據格式定義和數據操作定義。（一）面向對象設計模型架構的概念建筑、文學、音樂、機械、電子、計算機軟硬件等領域都會使用“架構（architecture）”這一概念。架構都提供了系統最高層的設計方案，以確保建筑、小說、樂曲、設備、計算機等系統滿足期望的特性。好的建筑應該美觀、堅固、實用好的計算機應用系統應該實用、好維護、可靠、性價比高架構師（architect）需要發現特定系統的最重要的關注點，設計某種折衷的總體方案以滿足關注點。架構包含系統的一組基本結構（structure），每種結構都有各種類型的部件（component）及其關系構成，架構描述了這些部件的組合、相互調用參照、通信以及其他動態交互。第二節面向對象設計（二）高層構架設計架構和結構的關系架構是抽象無形的，體現高層全局的決策，就像文章的中心思想和提綱。結構是具體有形的，體現決策的貫徹，如同文章的每個段落及細節描述。架構包含了結構的初步描述和決策。相同架構的系統，具體結構允許有差異。使用橋梁來比喻橋梁的架構設計可以使用草圖描述，架構決定了橋梁的基本結構部件。橋梁有梁式橋、拱橋、斜拉橋、懸索橋等架構斜拉橋的基本結構：索塔主梁斜拉索使用橋梁來比喻橋梁的結構設計則需要考慮各種部件的數量、材料、重量、形態等方面，是可以施工的嚴謹的結構圖。架構是抽象的，對結構進行了設計和限定，每座橋的結構是具體有形的、元素組合千變萬化高層構架設計的目的是開發系統的結構，它從對象設計模型的四個部分入手，構造應用系統的總體構架。1.問題領域部分設計問題領域部分設計包括與應用問題直接有關的全部類和對象。它的設計工作主要從以下五個方面對分析模型進行增補修改：（1）復用已有的構架和設計模式；（2）把與問題領域相關的類、相關類，建立類的層次結構；（3）創建一般化類；（4）改進系統性能；（5）加入較底層的構件。第二節面向對象設計（二）高層構架設計2.人機交互部分的設計用戶界面部分設計主要由以下幾個部分組成：（1）用戶分類及用戶任務描述；（2）設計命令層；（3）設計與用戶的詳細交互，并進行原型設計；（4）設計人機交互。3.任務管理部分的設計任務管理部分的設計包括以下幾個方面：（1）為任務命名，并簡要說明任務；（2）定義任務間的協調關系，標明是事件驅動還是時鐘驅動；（3）描述任務之間的通信，說明任務將從哪里取值，執行結果將送往何方。第二節面向對象設計（二）高層構架設計4.數據管理部分的設計數據管理部分提供在MIS中存儲和檢索對象的基本結構，包括對永久性數據的訪問和管理。數據管理的方法主要有三種：文件管理、關系數據庫管理和面向對象的數據庫管理。數據管理部分的設計包括以下兩個方面的內容：（1）數據存放設計；（2）設計相應的操作。它是指為每個需要存儲的對象和類增加用于存儲管理的屬性和操作，在類和對象的定義中加以描述第二節面向對象設計（二）高層構架設計第二節面向對象設計（三）類設計類設計關注系統行為如何被實現，因此必須完成以下事情：（1）完整的屬性集合，包括詳細說明的名稱、類型、可見性和一些默認值。（2）將分析類指定的操作轉化為一個或多個方法的完整集合。1.設計類及其獲取設計類是已經完成了規格說明的類，并且達到能夠被實現的程度。設計類來自兩個方面：（1）通過分析類的細化得到（2）應用程序框架第二節面向對象設計（三）類設計2.良好的設計類的特征（1）完整的和充分的；（2）原始的；（3）高內聚；（4）低耦合。返回本節目錄第二節面向對象設計二、信息系統體系結構設計信息系統體系結構（informationsystemarchitecture）是指計算機信息系統的各個組成部分之間的相互關系，它是硬件、軟件、算法和語言的綜合性概念。信息系統體系結構有集中式結構和分布式結構兩種類型，典型的代表是客戶機/服務器（client/server,C/S）和瀏覽器/服務器（browser/server,B/S）?，F代信息系統的部件通常分布于多個計算機系統和不同的地理位置上，因此B/S結構是當前分布式信息系統資源的資源結構形式。分層的含義基于組件的軟件開發，組件根據橫向位置劃分為多層（N-Layer）：下層組件負責對上層組件提供服務上層組件可以使用下層組件定義的服務，但下層組件對上層組件一無所知。層與層之間通常是不透明的，每一層都具有獨立的職責不同層的軟件構件可以分布在多臺機器上，也可以部署在同一臺機器上，形成物理上的多層（N-Tier）理解分層概念層次模型的理念就是將整個任務橫向劃分為不同級別，而不是縱向比如學校管理縱向劃分有教學、人事、財務、后勤等任務橫向劃分有主管校長（高層）、部門領導（中層）、普通員工（基層），或處、科、室計算機程序的組織結構也可以有縱向劃分和橫向劃分縱向：教師管理功能、學生管理功能、課程管理功能……橫向：界面窗體、業務邏輯類、數據訪問類……第二節面向對象設計二、信息系統體系結構設→客戶機/服務器體系結構數據庫界面窗口程序中包含所有的內容，如輸入輸出、界面邏輯控制、業務邏輯運算等。系統架構是兩層，應用架構沒有分層。第二節面向對象設計二、信息系統體系結構設→瀏覽器/服務器體系結構數據庫借還書組件讀者管理組件表示層（UI）業務邏輯層（BLL）數據訪問層（DAL）數據庫訪問組件細節看P143擴展的五層架構表現層：等同于三層中的表現層。控制層/中介層：是表現層和領域層的中介層，也稱應用控制器。主要表示業務邏輯中的工作流，一般針對于用例的事件流控制。此外還負責會話狀態、數據的合成或分解等事務。領域層：業務邏輯中的領域類的集合，不包含復雜工作流。數據映射層：負責將基于對象的領域層數據映射到數據庫關系表中的記錄。也稱為數據持久層，可自行開發或采用持久化框架。數據訪問層：負責數據庫表的增刪改查等操作。持久化框架中包含該層組件。返回本節目錄第二節面向對象設計三、軟件類設計（一）面向對象程序的工作原理（1）封裝：對象封裝了該對象實例所需的所有數據、對象類，對象的模板封裝了對象的邏輯程序。（2）信息隱蔽：指屬于一個對象的數據不為系統中的其他對象所見。另一個對象只有通過消息才能得到該對象的數據。（二）面向對象設計的目標（1）提高軟件生產效率：強化維護；提供重用類。（2）提高質量：對開發的最終產品進行仔細測試。（3）加強可維護性：把系統中易變的部分和比較穩定的部分分離開來。第二節面向對象設計三、軟件類設計（三）面向對象設計的基本任務對問題域外部可見的行為，描述實際的計算機系統實現所需的細節，包括人機交互、應用程序、數據庫、和網絡的細節。補充需求細節并檢查需求。構造系統并確定其表現形式（包括其構架）OOD階段需要建立的模型如下：（1）設計類圖：是對類圖的擴展，增加了屬性和方法細節。（2）包圖：用于標志一個完整系統的主要部分。（3）構件圖：表示構件及其之間是如何相互關聯的。（4）部署圖：表示結點及其之間是如何相互關聯的。第二節面向對象設計三、軟件類設計（四）設計類圖設計類圖的一個基本思想是將類模型層次化，形成類的類型體系結構，如下圖所示用戶界面類業務/領域類持久類永久存儲系統類類的類型體系結構第二節面向對象設計三、軟件類設計（四）設計類圖1.建立類的類型體系結構的原因（1）好的類型體系結構能夠對某一特點的層進行修改而不影響任何其他層，這將有助于提高系統的可擴展性和可維護性；其次，層應該是模塊化的，即只要接口不變，可以重寫某一層或替換某一層，從而提高系統的可移植性。（2）可以減少類間的耦合從而增加其可移植性。（3）同一層中允許類之間的協作。（4）協作還可發生在箭頭相連的層中的類之間。第二節面向對象設計三、軟件類設計（四）設計類圖2.類的類型體系結構（1）用戶界面類：也稱為接口類或邊界類，是實現系統的主要用戶界面元素，包含應用程序中用戶界面部分的代碼。（2）業務/領域類：也稱為分析類，實現與業務領域相關的概念。這些類通常在分析階段確定。（3）持久類：將永久存儲、檢索和刪除對象的能力封閉起來，使底層的存儲技術不暴露出來。（4）系統類：為應用系統提供與OS相關的功能，通過將與OS相關的特性包裝起來，使軟件與OS分離，增加系統的可移植性。包（Package）是一種邏輯分組手段，可以取UML模型中的任何一種事物，將相關成分聚在一起，以構成更高層的組織單元——包。最常用的方法是將類以包為單位進行分組，比如上一節提到的層，每一層中的所有類組成一個包。一個包可以包含其它的包，高層包被分成若干子包，子包又可以在分成更小的包。包之間的關系可以通過訪問依賴來說明，訪問依賴表明一個包（源包）有權引用另一個包（目標包）中的元素。在兩個同等層次的包之間，除非存在顯示的訪問關系，否則一個包中的元素不能引用另一個包中的元素。第二節面向對象設計三、軟件類設計（五）設計包圖分包（軟件類的分組）有兩種原則：共同封閉原則（CommonClosurePrinciple）。一個包中的各個類應該是由于相似的原則而改變，即將一組職責相似、但以不同方式實現的類歸為一個包中。比如按照層來進行分包就是這種類型。共同復用原則（CommonReusePrinciple）。一個包中的各個類應該一起被復用，復用其中一個可能需要同時考慮同一個包中的其它協作類。通常和業務功能相關。第二節面向對象設計三、軟件類設計（五）設計包圖包圖包圖用來描述包及其依賴關系。當表現層包中的類要使用領域包中的領域類提供的服務時，表示包就依賴于領域包。訪問依賴用虛線箭頭表示構件（component）是系統中實際存在的可更換部分，它實現特定的功能，符合一套接口標準并實現一組接口。構件是可復用的軟件組成成份，可被用來構造其他軟件。在系統中采用構件軟件程序不需要重新編譯，也不需要構件自身的源代碼并且不局限于某一種編程語言，所以構件的復用也稱為二進制復用（binaryreuse），因為它是建立在接口而不是源代碼級別的復用。構件及其關系使用UML構件圖描述。第二節面向對象設計三、軟件類設計（六）設計構件圖第二節面向對象設計三、軟件類設計（六）設計構件圖在UML中定義了五種標準構件造型：（1）可執行的，即一個直接可執行模塊。（2）庫，即一個靜態或動態對象庫模塊。（3）表，即一個數據庫表。（4）文件，即一段源代碼或數據文檔。（5）文檔，即可讀的文檔。構件圖是顯示代碼自身結構的實現級別的圖標。構件圖由諸如源代碼文件、二進制代碼文件、可執行文件或動態鏈接庫（DLL）這樣的構件構成，并通過依賴關系相連接。

使用構件圖可將系統劃分為多個內聚構件。通常，構件圖中的每個構件都會在類圖中有更為詳細的說明。構件圖表示了構件之間的依賴關系。構件之間唯一的關系是依賴關系，依賴關系要求一個類要在另一個類之前編輯。每個構件實現（支持）一些接口，并使用另一些接口。如果構件間的依賴關系與接口有關，那么構件可以被具有同樣接口的其他構建替代。構件圖構件之間存在依賴關系：DataAccess構件用于實現數據存取訪問，對外提供接口名為SearchInDB（查詢數據庫，接口參數等細節省略）。Book構件實現圖書的管理，對外提供SearchBook（查詢圖書）和ExportToXml（導出圖書為XML文件）兩個接口。Book構件需要使用DataAccess構件提供的接口，即構件Book依賴于DataAccess構件。

DataAccessBookSearchBookExportToXmlSearchInDB部署圖：描述一個運行時的硬件結點，以及在結點上運行的軟件組件的靜態視圖。部署圖顯示了系統的硬件、安裝在系統上的軟件以及用于連接異構的機器之間的中間件。第二節面向對象設計三、軟件類設計（七）設計部署圖如何閱讀部署圖BS客戶端支持IE6億傻姑娘和FF1.5以上版本，通過Http請求CS客戶端是Windows系統，需要按.net1.1，sw.exe

是客戶端程序，通過WebService與服務器通信服務器是IIS，.Net1.1各個組件之間相互依賴，通過ADO.Net

訪問數據庫數據庫為Oracle9i部署圖的主要元素?節點：它代表一個運行時的計算資源（一臺實體設備），例如一臺計算機、一個工作站等其它設備?節點的概念和構件有許多相同之處，例如二者有多名稱，都可以參與依賴、泛化和關聯關系，都可以被嵌套，都可以有實例，都可以參與交互。但它們之間也存在明顯的區別：構件是參與系統執行的事物，而節點是執行構件的事物；構件表示邏輯元素的物理打包，而節點表示構件的物理部署?本圖中建模了四個節點：B/S客戶端、C/S客戶端、IIS服務器和數據庫服務器?連接：節點之間最常見的關系就是關聯關系（用一根實線表示）。為了更好地表示兩個節點之間的關系，我們可以通過“約束”來對連接進行描述。源節點目標節點約束（描述）含義B/S客戶端IIS服務器{HTTP+Network}網絡連接，使用HTTP協議C/S客戶端IIS服務器{HTTP+SOAP+Network}網連接，通過WebService訪問服務IIS服務器DBS服務器{ADO.NET}.NET提供的數據庫訪問解決方案部署圖的補充元素?處理器（《process》）：具有處理能力的節點，即可以執行構件?設備（《device》）：沒有處理能力的節點，至少是不關心其處理能力的節點。例如打印機、IC卡讀寫器，如果我們的系統不考慮它們內部的芯片，就可建模為設備?節點屬性和操作：可以為一個節點提供處理器速度、內存容量、網卡數量等屬性，可以為其提供啟動、關機等操作?自定義構造型圖標創建一個部署模型的目的包括：（1）探究系統投產的相關問題。（2）探究用戶系統和生產環境中的其他系統的依賴關系，這些系統可能是已經存在，或是將要引入的。（3）描述一個商業應用主要的部署構件。（4）設計一個嵌入系統的硬件和軟件結構。（5）描述一個組織的硬件/網絡基礎結構。第二節面向對象設計三、軟件類設計（七）設計部署圖創建部署圖的一些指南如下：（1）通用準則：在特定的項目圖上注明軟件組件，集中在企業級圖上的節點和通信關聯。（2）結點和組件：用描述性術語命名結點，僅僅建模重要的軟件組件，為組件一致地應用一致版型；把可視化的版型應用到結點。（3）依賴和通信關聯：用版型來注明通信協議；僅僅建模組件間的關鍵性依賴。第二節面向對象設計三、軟件類設計（六）設計構件圖第二節面向對象設計三、軟件類設計（八）用戶界面設計、DBS設計的集成用面向對象方法進行設計類的設計時，不必太在意用戶界面的設計和數據庫的設計對設計類的影響。應該注意的問題：應用程序和用戶界面的集成首先要求選擇一個適當的設計工具，利用工具所提供的組件進行表單、報表等界面類的設計，并在應用類的方法中添加用以訪問用戶界面類方法的邏輯，因此應用程序類的設計應最好能和用戶界面的設計結合起來考慮，這樣，在設計時就能確定哪些消息發送給哪些用戶界面方法。第二節面向對象設計三、軟件類設計（八）用戶界面設計、DBS設計的集成對數據庫的訪問也可以通過一系列的數據庫來實現，考慮到有些面向對象語言支持直接讀寫數據庫，二有些語言則要求提供一些對數據庫接口對象的特殊調用，因此，數據庫訪問有可能較為復雜。為確保在設計階段能將應用程序和數據庫有機集成，重要的一點是盡早確定所要用的目標編程語言和數據庫管理系統。返回本節目錄四、面向對象設計原則總的原則抽象與復用（封裝、信息隱藏）松耦合面向功能模塊設計功能內聚的模塊，避免使用全局數據模塊傳遞的參數作數據用，并且盡可能少模塊內語句數一般為50-100面向對象單一職責、開放封閉、里氏替換、依賴倒置…面向服務標準化服務合約、服務松散耦合、服務抽象、服務可復用、服務自治、服務無狀態、服務可發現性和服務可組合性4.1抽象與復用模塊化：模塊是廣泛意義上的建模元素，可以是子過程或函數、類、構件、服務、流程等。模塊化強調抽象和封裝。好的抽象能讓人們集中精力考慮問題實質，而忽略問題中與主旨無關的次要部分。好的封裝能讓一個部件暴露出其最本質的內容，讓人們快速理解和使用它，不讓復雜性蔓延。模塊化的另一個好處就是復用。不同業務流程中重復對一組數據執行同一操作，對這類數據和操作進行合理抽象和封裝后，就能在多個地方進行復用，節約了成本，提高了效率。四、面向對象設計原則4.2松耦合任何事物只要相互之間存在某種關系，就意味著事物間的耦合。緊耦合：是指應用系統的各部件在功能上、數據上或結構上是緊密相連的，因而每當某個部件發生變化時，相關部分的也要隨之進行部分甚至整個應用程序的調整。松耦合：面對變化則具有很好的適應能力和應變能力。耦合和內聚有著密切關系，通常高內聚就會帶來松耦合。四、面向對象設計原則4.3單一職責原則SRP即內聚性原則。單一職責的模塊—>單一職責的類。一個類承擔的職責過多，某個職責的變化可能會削弱或者抑制該類完成其他職責的能力，并影響到構建、測試和部署等活動。多職責會導致脆弱的和不易理解的設計。職責過多的職工類四、面向對象設計原則分離職責到不同的類對“雜湊類”進行分解4.4開放封閉原則OCP軟件實體（類、模塊、函數等）應該是“可擴展”的，但又是“不可修改”的?！白兓攀遣蛔兊恼胬怼保ㄟ^設計使得系統能夠適應改變又能保持相對穩定，避免僵化的設計。開放-封閉原則實現兩個目標：“對于擴展是開放的”（openforextension）。這意味著模塊的行為是可擴展的，從而使其具有滿足那些改變的新需求?！皩τ诟氖欠忾]的”（closedformodification）。當對模塊進行擴展時，不必改動模塊的源代碼或二進制代碼（如dll/jar文件）。自相矛盾嗎？四、面向對象設計原則什么是不封閉、不開放如下的模型可以處理月薪制（SALARIED）和時薪制（WAGED）職工工資，時薪制根據考勤卡計算。如果增加了一種新的職工類型，其計酬方式不同（如提成制），則必定要修改Employee類（即Employee是不封閉的），如果讓其封閉，開放擴展又是不可能的。如何改進利用抽象機制封閉：Employee及其已有的子類是封閉的，不可改開放：可以派生新的子類，實現新的需求，可擴展4.5Liscov替換原則LSP實現OCP的主要機制是抽象和多態。怎樣設計最佳的繼承層次，BarbaraLiskov在1988年首次提出LSP：子類型（subtype）必須能夠替換掉它們的基類型（basetype）。假設S是T的子類型，所有使用了T對象的程序(也稱客戶程序)，用S對象替換T對象后，仍能成功執行。LSP是多態順利實現的保證，從而使OCP成為可能。因為正是子類型的可替換性才使得使用基類的模塊在無需修改的情況下就可以擴展。增加或修改任何一個子類型，基類不用修改（封閉）基類的使用者（客戶程序）通過多態得到擴展或修改過的行為（開放）。四、面向對象設計原則一個使用繼承的例子正方形是長方形的一種特例會發生什么情況？正方形有獨特的行為方式通過覆蓋父類的有關方法來實現子類行為客戶程序如何能了解長方形的使用者按照長方形的特點來調用SetWidth和SetHeight兩個函數，并測試面積，代碼如下：voidtestArea(Rectangle&r){ r.SetWidth(5); r.SetHeight(4); assert(r.Area()==20);}如果傳遞進來的是Square對象又會如何呢？顯然會出現斷言錯誤，測試失敗。對于客戶程序來說，模型中的層次結構是脆弱的，因為違反了LSP替換原則，Square對象和Rectangle對象的行為方式不相容，這樣的抽象即使采用虛函數也無法實現子類對父類的替換。違反LSP替換原則，多態的使用是不安全的。4.6依賴倒置原則DIP高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象（也稱針對抽象編程）；抽象不應該依賴于細節，細節應該依賴于抽象。結構化設計時，高層模塊總是依賴于低層模塊。面向對象的分層模式中也是高層的類依賴于底層的類。按照自上而下的依賴關系，高層的策略設置模塊往往是無法重用的，如果設法讓高層模塊獨立于低層模塊，則實現重用就變為可能。依賴倒置原則的啟發式建議是“依賴于抽象”，具體做法是將高層需要的服務聲明為抽象接口，高層使用這些接口，低層模塊實現這些接口，使得高層不再依賴于低層，而是依賴于抽象接口，同樣低層也依賴于抽象接口。傳統的依賴層次高層使用低層的對象及其服務都依賴于抽象設計抽象接口，上層類使用接口，下層類實現接口這樣Button類也可以得到重用，也許是開關燈，也許是開關電視，根據創建具體對象完成多態的行為。4.7合成復用原則

合成復用原則又稱為組合/聚合復用原則(Composition/AggregateReusePrinciple,CARP)，其定義如下：合成復用原則：盡量使用對象組合，而不是繼承來達到復用的目的。

合成復用原則就是在一個新的對象里通過關聯關系（包括組合關系和聚合關系）來使用一些已有的對象，使之成為新對象的一部分；新對象通過委派調用已有對象的方法達到復用功能的目的。簡言之：復用時要盡量使用組合/聚合關系（關聯關系），少用繼承。四、面向對象設計原則4.7合成復用原則由于組合或聚合關系可以將已有的對象（也可稱為成員對象）納入到新對象中，使之成為新對象的一部分，因此新對象可以調用已有對象的功能，這樣做可以使得成員對象的內部實現細節對于新對象不可見，所以這種復用又稱為“黑箱”復用，相對繼承關系而言，其耦合度相對較低，成員對象的變化對新對象的影響不大，可以在新對象中根據實際需要有選擇性地調用成員對象的操作；合成復用可以在運行時動態進行，新對象可以動態地引用與成員對象類型相同的其他對象。4.7合成復用原則下面通過一個簡單實例來加深對合成復用原則的理解：Sunny軟件公司開發人員在初期的CRM系統設計中，考慮到客戶數量不多，系統采用MySQL作為數據庫，與數據庫操作有關的類如CustomerDAO類等都需要連接數據庫，連接數據庫的方法getConnection()封裝在DBUtil類中，由于需要重用DBUtil類的getConnection()方法，設計人員將CustomerDAO作為DBUtil類的子類，初始設計方案結構如圖1所示：4.7合成復用原則下面通過一個簡單實例來加深對合成復用原則的理解：圖1

初始設計方案結構圖4.7合成復用原則下面通過一個簡單實例來加深對合成復用原則的理解：隨著客戶數量的增加，系統決定升級為Oracle數據庫，因此需要增加一個新的OracleDBUtil類來連接Oracle數據庫，由于在初始設計方案中CustomerDAO和DBUtil之間是繼承關系，因此在更換數據庫連接方式時需要修改CustomerDAO類的源代碼，將CustomerDAO作為OracleDBUtil的子類，這將違反開閉原則?！井斎灰部梢孕薷腄BUtil類的源代碼，同樣會違反開閉原則。】

現使用合成復用原則對其進行重構。4.7合成復用原則根據合成復用原則，我們在實現復用時應該多用關聯，少用繼承。因此在本實例中我們可以使用關聯復用來取代繼承復用，重構后的結構如圖2所示：圖2

重構后的結構圖4.7合成復用原則在圖2中，CustomerDAO和DBUtil之間的關系由繼承關系變為關聯關系，采用依賴注入的方式將DBUtil對象注入到CustomerDAO中，可以使用構造注入，也可以使用Setter注入。如果需要對DBUtil的功能進行擴展，可以通過其子類來實現，如通過子類OracleDBUtil來連接Oracle數據庫。由于CustomerDAO針對DBUtil編程，根據里氏代換原則，DBUtil子類的對象可以覆蓋DBUtil對象，只需在CustomerDAO中注入子類對象即可使用子類所擴展的方法。例如在CustomerDAO中注入OracleDBUtil對象，即可實現Oracle數據庫連接，原有代碼無須進行修改，而且還可以很靈活地增加新的數據庫連接方式。4.8接口隔離原則

接口隔離原則的含義是：建