軟件分析與設計基礎

軟件分析與設計基礎第一頁，共一百四十三頁，編輯于2023年，星期三經驗和教訓表明:1)軟件開發(fā)需要遵循軟件工程方法論的指導，軟件分析與設計質量決定軟件產品的質量2)合理的軟件分析與設計建立在對軟件需求正確理解的基礎上，對軟件需求的深入理解是軟件開發(fā)工作獲得成功的前提和關鍵3)要開發(fā)出好的軟件產品，首先必須知道用戶的需求，并在充分了解用戶需求的基礎上，對用戶的業(yè)務需求建模，并進行相應的分析與設計，才能生產出真正符合用戶要求且生命周期長的軟件產品。

第二頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

傳統(tǒng)的軟件工程方法：結構化分析（StructruedAnalysis，SA）結構化設計（StructruedDesign，SD）。

第三頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

2.1.1結構化分析

結構化分析是20世紀70年代后期提出的，是一種基于功能分解的需求分析方法，適用于分析大型數據處理系統(tǒng)。與結構化設計(SD)一起聯(lián)合使用，能較好地實現(xiàn)一個軟件系統(tǒng)的研制。它是一種面向數據流，自頂向下、逐步求精進行需求分析的方法。

它通常用數據流圖表達需求,以數據字典表示數據的邏輯定義。

第四頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

SA方法的特點：核心思想是自頂向下、逐步求精基本手段是分解和抽象

所謂分解就是把大問題分割成若干小問題，把復雜度降低到人們可以掌握的程度，然后分別解決。所謂抽象就是把細節(jié)略去，先考慮最本質的東西?！鍪褂脭祿鲌D、數據字典等規(guī)范化工具描述需求。第五頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計使用SA方法進行軟件需求分析的步驟：(1)建立當前系統(tǒng)的具體模型分析當前系統(tǒng)和現(xiàn)實環(huán)境，描述當前系統(tǒng)的工作方式，客觀地反映現(xiàn)實世界的實際情況。(2)抽象出當前系統(tǒng)的邏輯模型就是在理解當前系統(tǒng)“怎么做”的基礎上，抽取出“做什么”的本質，從當前系統(tǒng)的具體模型抽象出當前系統(tǒng)的邏輯模型。第六頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計(3)建立目標系統(tǒng)的邏輯模型所謂目標系統(tǒng)是指將要開發(fā)的由計算機處理的系統(tǒng)。方法如下：在數據流圖上把目標系統(tǒng)與當前系統(tǒng)在邏輯上不同的部分找出來，這部分就是要改變的部分。將要改變部分抽象為一個加工，再進行逐步分解，最后就可獲得目標系統(tǒng)的邏輯模型。第七頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計1.數據流圖

數據流是數據在系統(tǒng)內的傳輸途徑，數據流圖從數據傳遞和加工的角度，以圖形的方式刻畫數據流從輸入到輸出的變換過程。數據流圖是結構化系統(tǒng)分析的主要工具，它去掉了具體的組織機構、工作場所、物質流等，僅反映信息和數據存儲、流動、使用以及加工的情況。

第八頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計①數據流圖的基本元素包括數據流、加工、數據存取文件、輸入數據的源點和輸出數據的匯點4類。常采用如圖2-1所示的圖形符號：圖2-1數據流圖基本圖形符號第九頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

繪制數據流圖時，應先找出系統(tǒng)的數據源點與匯點及對應的輸入數據流與輸出數據流，然后從輸入數據流(即系統(tǒng)的源點)出發(fā)，按照系統(tǒng)的邏輯需要，逐步畫出系列邏輯加工，直到所需的輸出數據流(即系統(tǒng)的匯點)。

第十頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計數據流在傳遞過程中，需要一些加工處理。常見的加工關系及對應的圖形符號如圖2-2所示。圖2-2數據流圖加工關系第十一頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計數據流圖應用舉例：取款單信息付款儲戶核查登錄賬卡存折存折信息取款信息銀行取款過程的數據流圖反饋信息付款信息可取款信息第十二頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計②分層數據流圖較復雜的實際問題中，僅用一個數據流圖很難表達數據處理過程和數據加工情況，需要采用“先全局后局部，先整體后細節(jié)，先抽象后具體”的逐步求精原則，按照問題的層次結構逐步分解。首先確定頂層數據流圖，把整個數據處理過程抽象為一個加工，它的輸人數據和輸出數據實際上反映了系統(tǒng)與外界環(huán)境的接口，這就是頂層數據流圖。然后在上一層數據流圖的基礎上進一步細化，直到數據流圖的加工不能再分解為止。

第十三頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

第十四頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

③畫數據流圖的步驟和原則畫數據流圖的基本步驟是自外向內，自頂向下，逐層細化，完善求精，并且需要遵循以下基本原則：頂層數據流圖上的數據流必須封閉在外部實體之間。每個加工至少有一個輸入數據流和一個輸出數據流。在數據流圖中，需按層給加工進行編號。編號應表明該加工處在哪一層，以及與上下層的父圖與子圖的對應關系。任何一個數據流子圖必須與它上一層的一個加工對應，兩者的輸入數據流和輸出數據流必須一致，即父圖與子圖的平衡。圖上每個元素都必須有名字，加工的名字應當表明做什么事情。第十五頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

數據流圖畫法舉例：（培訓中心管理系統(tǒng)數據流圖）第十六頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

第十七頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

第十八頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

第十九頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計2.數據字典

數據字典是各類數據描述的集合。它通過對數據項和數據結構的定義來描述數據流、數據存儲的邏輯內容。通常包括數據項、數據結構、數據流、數據存儲、處理過程和外部實體等6個部分。第二十頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計①數據項

數據項是數據的最小組成單位，若干個數據項可以組成一個數據結構。對數據項的描述通常包括以下內容。數據項描述＝{數據項名，數據項含義說明，別名，數據類型，長度，取值范圍，取值含義，與其他數據項的邏輯關系}第二十一頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計②數據結構數據結構反映了數據之間的組合關系。一個數據結構可以由若干個數據項組成，也可以由若干個數據結構組成（嵌套數據結構），或由若干個數據項和數據結構混合組成。對數據結構的描述通常包括以下內容。數據結構＝{數據結構名，含義說明，組成：{數據項或數據結構}}第二十二頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計③數據流數據流是數據結構在系統(tǒng)內的傳輸路徑。對數據流的描述通常包括以下內容。數據流描述＝{數據流名，說明，數據流來源，數據流去向，組成：{數據結構}，平均流量，高峰期流量}

④數據存儲數據存儲是數據結構停留或保存的地方。數據存儲的描述通常包括以下內容。數據存儲＝{數據存儲名，說明，編號，流入的數據流，流出的數據流，組成：{數據結構}，數據量，存取方式}第二十三頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計⑤處理過程處理過程應描述處理邏輯的功能，詳細地描述其輸入輸出的數據流以及這些數據的基本轉換路徑和策略說明性信息，對處理過程的描述通常包括以下內容。處理過程＝{處理過程名，編號，說明，輸入：{數據流}，輸出：{數據流}，處理：{簡要說明}}

第二十四頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計⑥外部實體外部實體是系統(tǒng)的“人-機”界面，系統(tǒng)的數據流由外部實體流入，經過加工處理之后，向外部實體流出。外部實體的描述如下。外部實體={外部實體的名稱，編號，輸入：{數據流}，輸出：{數據流}}第二十五頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計3.實例--學籍管理分析

學籍管理涉及的內容比較多，業(yè)務邏輯也較復雜。在不失一般性的基礎上，本實例簡化了學籍管理的業(yè)務邏輯.（1）需求描述工作內容：

■建立學生的學籍

■匯總每學期學生的學分■學生每門課程的的考試成績

■學生的平均成績

■匯總各分數段的人數

■各種查詢第二十六頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計涉及人員：■管理人員■班主任■任課教師■學生

系統(tǒng)初步：系統(tǒng)性質：MIS軟件。系統(tǒng)使用者：管理人員、班主任、教師、學生等。系統(tǒng)運行環(huán)境：網絡運行。第二十七頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計表2-1學籍管理主要功能表功能名稱功能說明學生管理登記學生的基本信息（姓名、性別、班級等），并提供查詢功能。課程管理登記課程基本情況（課程名稱、開課學期、課程類型、學分等），提供查詢教師管理登記教師基本情況（姓名、年齡、性別、學歷等），提供查詢統(tǒng)計成績管理登記學生各門課程的考試成績、提供查詢、統(tǒng)計功能授課管理登記教師講授課程、授課地點、授課學期，提供查詢功能編碼維護維護系統(tǒng)中使用的編碼（如職稱編碼、學院編碼、班級編碼等）第二十八頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計（2）分析設計頂層數據流圖

管理人員、教師、班主任、學生等是數據輸入的源點和數據輸出的匯點。學生基本信息、教師信息、課程信息、教學計劃、考試成績等是數據存儲文件。

圖2-4學籍管理頂層數據流圖第二十九頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計（3）逐步細化數據流圖根據表2-1中列出的學籍管理的主要功能，將學籍管理加工細化分解為學生管理、課程管理、教師管理、成績管理、授課管理和編碼維護等子加工。圖2-5學籍管理1層數據流圖第三十頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

根據實際業(yè)務，分析各處理流程，直到數據流圖中出現(xiàn)的每個加工處理都不能再分解為止。成績管理可以繼續(xù)細化為如圖2-6所示的成績管理數據流圖。圖2-6成績管理數據流圖第三十一頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

圖2-6所示的成績錄入和成績查詢都可以繼續(xù)分解。例如：成績錄入加工可以繼續(xù)細化為增加成績、修改成績、刪除成績等子加工，為了方便成績錄入，還需要班級學生名單查詢子過程，因此圖2-6所示的成績管理的2層數據流圖的成績錄入加工可以繼續(xù)細化分解為圖2-7所示成績錄入的3層數據流圖。圖2-7細化后的成績錄入數據流圖第三十二頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計（4）制定整理數據字典數據字典是系統(tǒng)中各類數據描述的集合。通常包括數據項、數據結構、數據流、數據存儲、處理過程和外部實體等6個部分。

①數據項的描述以圖2-7中的“學號”數據項為例說明：數據項名稱：學號含義：唯一標識每個學生別名：類型：字符型長度：5

取值范圍：00000至99999

取值含義：前2位標別該學生所在年級，后3位為順序編號。第三十三頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

②數據流的描述以“學生名單”數據流為例。數據流名稱：學生名單說明：某班全部學生的名單數據流來源：班級學生名單查詢數據流去向：班級學生名單顯示組成（包含的數據項）：班級、學號、姓名平均流量：高峰期流量：第三十四頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

③數據存儲的描述以數據存儲“考試成績”為例。數據存儲：考試成績說明：保存學生各門課的考試成績流入數據流：新增的成績、修改后的成績流出數據流：原成績組成：學號、姓名、成績數據量：3000（學生）*15（課程）存取方式：隨機存取第三十五頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計④處理過程的描述以處理過程“增加成績”為例。處理過程：增加成績說明：錄入一個或一批學生某門課程的考試成績輸入：添加成績要求輸出：新增的成績處理：在考試成績數據存儲中增加一個或一批學生的考試成績。第三十六頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計2.1.2結構化設計

通常把設計工作劃分為概要設計和詳細設計兩個階段。概要設計階段的主要任務是，通過仔細分析需求規(guī)格說明，對軟件進行功能分解，從而把軟件劃分為模塊，并且設計出完成預定功能的模塊結構。詳細設計階段的主要任務是，詳細地設計每個模塊，確定完成每個模塊功能所需要的算法和數據結構。第三十七頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計結構化設計的主要原則如下：抽象就是把事物本質的共同特性提取出來而不考慮其他細節(jié)。軟件設計中考慮模塊化解決方案時，可以定出多個抽象級別。抽象的層次從概要設計到詳細設計逐步降低。模塊化模塊是指把一個待開發(fā)的軟件分解成若干小的簡單的部分。每個模塊可以完成一個特定的子功能，各個模塊可以按一定的方法組裝起來成為一個整體，從而實現(xiàn)整個系統(tǒng)的功能。

第三十八頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計信息隱蔽指在一個模塊內包含的信息（過程或數據），對于不需要這些信息的其他模塊來說是不能訪問的。模塊獨立性模塊獨立性是指每個模塊只完成系統(tǒng)要求的獨立的子功能，并且與其他模塊的聯(lián)系最少且接口簡單。衡量軟件的模塊獨立性使用耦合性和內聚性兩個定性的度量標準。

第三十九頁，共一百四十三頁，編輯于2023年，星期三2.1結構化開發(fā)方法①內聚性是一個模塊內部各個元素間彼此結合的緊密程度的度量。按照內聚性由弱到強的順序可分為：偶然內聚、邏輯內聚、時間內聚、過程內聚、通信內聚、順序內聚、功能內聚。②耦合性是模塊間互相連接緊密程度的度量。按照耦合性由弱到強的順序可分為：非直接耦合、數據耦合、標記耦合、控制耦合、外部耦合、公共耦合、內容耦合。一般來說，設計軟件時應盡量使用數據耦合，減少控制耦合，限制外部環(huán)境耦合和公共耦合，杜絕內容耦合。耦合性與內聚性是模塊獨立性的兩個定性標準，耦合與內聚是相互關聯(lián)的。在程序結構中，各模塊的內聚性越強，則耦合性越弱。一般較優(yōu)秀的軟件設計，應盡量做到高內聚，低耦合。第四十頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

1)非直接耦合。如果兩個模塊之間沒有直接關系，它們之間的聯(lián)系完全是通過主模塊的控制和調用來實現(xiàn)的，這就是非直接耦合。

2)數據耦合。如果一個模塊訪問另一個模塊時，彼此之間是通過簡單數據參數(不是控制參數、公共數據結構或外部變量)來交換輸入、輸出信息的，則稱這種耦合為數據耦合。第四十一頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

3)標記耦合。如果一組模塊通過參數表傳遞記錄信息，就是標記耦合。這個記錄是某一數據結構的子結構，而不是簡單變量。

4)控制耦合。如果一個模塊通過傳送開關、標志、名字等控制信息，明顯地控制選擇另一模塊的功能，就是控制耦合。

5)外部耦合。一組模塊都訪問同一全局簡單變量而不是同一全局數據結構，而且不是通過參數表傳遞該全局變量的信息，則稱之為外部耦合。第四十二頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

6)公共耦合。若一組模塊都訪問同一個公共數據環(huán)境，則它們之間的耦合就稱為公共耦合。

7)內容耦合。當一個模塊直接修改或操作另一個模塊的數據，或者直接轉入另一個模塊時，就發(fā)生了內容耦合。

第四十三頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

1)偶然性內聚。

偶然性內聚又稱為巧合性內聚。當模塊內各部分之間沒有聯(lián)系，或者即使有聯(lián)系，這種聯(lián)系也很松散，則稱這種模塊為巧合內聚模塊。

2)邏輯性內聚。

這種模塊把幾種相關的功能組合在一起，每次被調用時，由傳送給模塊的判定參數來確定該模塊應執(zhí)行哪一種功能。第四十四頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

3)時間性內聚。如果一個模塊內的幾個功能必須在同一時間內執(zhí)行，但這些功能只是因為時間因素關聯(lián)在一起，則稱為時間性內聚。

4)過程性內聚。如果一個模塊內部的處理成分是相關的，而且這些處理必須以特定的次序執(zhí)行，則稱為過程性內聚。

5)通信性內聚。如果一個模塊內各功能部分都使用了相同的輸入數據，或產生了相同的輸出數據，則稱之為通信內聚模塊。第四十五頁，共一百四十三頁，編輯于2023年，星期三

6)信息性內聚。如果一個模塊內完成許多功能,每個功能都有各自的入口點,并且代碼相對獨立,但所有功能都在相同的數據結構上完成,則該模塊具有信息性內聚。

7)功能性內聚。一個模塊中各個部分都是完成某一具體功能必不可少的組成部分，或者說該模塊中所有部分都是為了完成一項具體功能而協(xié)同工作，緊密聯(lián)系，不可分割，則稱該模塊為功能內聚模塊。第四十六頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計1.概要設計概要設計的基本任務是：（1）設計軟件系統(tǒng)結構在需求分析階段，已經把系統(tǒng)分解成層次結構，而在概要設計階段，需要進一步分解，劃分為模塊以及模塊的層次結構。劃分的具體過程是：①將一個復雜的系統(tǒng)按功能劃分成模塊；②確定每個模塊的功能；③確定模塊之間的調用關系；④確定模塊之間的接口，即模塊之間傳遞的信息；⑤評價模塊結構的質量。第四十七頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計（2）數據結構及數據設計數據設計是實現(xiàn)需求定義和規(guī)格說明過程中提出的數據對象的邏輯表示。數據設計的具體任務是：

■確定輸入、輸出文件的詳細數據結構；■結合算法設計，確定算法所必需的邏輯數據結構及其操作；■確定對邏輯數據結構所必須的那些操作的程序模塊，限制和確定各個數據設計決策的影響范圍；■需要與操作系統(tǒng)或調度程序接口所必需的控制表進行數據交換時，確定其詳細的數據結構和使用規(guī)則；■數據的保護性設計；■防衛(wèi)性、一致性、冗余性設計。第四十八頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計（3）編寫概要設計文檔。

■概要設計說明書

■數據庫設計說明書

■集成測試計劃等。（4）概要設計文檔評審。對設計部分是否完整地實現(xiàn)了需求中規(guī)定的功能、性能等要求，設計方案的可行性，關鍵的處理及內外部接口定義正確性、有效性，各部分之間的一致性等都要進行評審。第四十九頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

概要設計的設計過程為：

(1)分析數據流圖，弄清楚數據流加工的過程；

(2)根據數據流圖確定數據流圖的類型；

(3)從數據流圖導出系統(tǒng)的初始軟件結構圖；

(4)改進軟件結構圖，直到符合要求為止；

(5)復查。第五十頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計數據流圖的類型

◆轉換處理型是對輸入數據流進行轉換而得到輸出數據流的處理。處理過程由輸入數據流、變換數據流和輸出數據流3步組成。輸入加工輸入信息轉換加工內部輸入輸入加工內部結果輸出信息第五十一頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

◆事務處理型是對輸入數據流進行某種加工后，按加工的結果選擇一個輸出數據流繼續(xù)執(zhí)行的處理。事務處理中，輸入數據流稱為事務流，加工稱為事務中心，若干平行數據流稱為事務路徑。事務中心事務流P2事務路徑2P1事務路徑1P3事務路徑3第五十二頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

常用的軟件結構設計工具是結構圖（SC，StructureChart），也稱程序結構圖。使用結構圖描述軟件系統(tǒng)的層次和分塊結構關系，它反映了整個系統(tǒng)的功能實現(xiàn)以及模塊與模塊之間的聯(lián)系與通訊。

表示模塊，框內用文字標記模塊名。箭頭表示模塊間的調用關系；邊上的小箭頭表示調用時模塊間傳送的數據，小箭頭的方向表示傳送信息的方向。表示上屬模塊有條件地調用下屬模塊。表示上屬模塊重復調用下屬模塊。第五十三頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

第五十四頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計轉換分析使用轉換分析技術可以把轉換型處理數據流圖轉換為標準結構。（有了標準結構就可根據軟件結構的度量準則、模塊化準則、模塊獨立性準則完善軟件結構，從而得到結構良好的最終結構圖）。

◆

轉換分析步驟為：確定數據流圖的類型；確定輸入流、轉換流、輸出流的流界；進行一級分解，設計上層模塊；進行二級分解，設計中下層模塊；進一步細化。

第五十五頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

（1）確定數據流圖的類型（2）確立流界主要確定輸入流和輸出流的邊界，獨立出中心流。

◆

找出輸入流的終點

◆

找出輸出流的起點

◆

找出中心加工

4號加工1號加工A2號加工B中心加工C3號加工DEF輸入輸出轉換流第五十六頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

(3)進行一級分解，設計上層模塊。

在中心加工位置設計一個主模塊，命名為M，其功能是控制整個軟件結構，完成系統(tǒng)所要做的各項工作，為輸人流設計一個輸入控制模塊，功能是為主模塊提供輸入信息。為輸出流設計一個輸出控制模塊CO，功能是為主模塊提供數據輸出。為中心設計一個轉換控制模塊CT，功能是控制所有內部數據的操作。MCTCICOCCDD第五十七頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

(4)進行二級分解，設計中下層模塊。自頂向下，逐步細化，為第一層的每一個輸入模塊、輸出模塊、轉換模塊設計從屬模塊.

為輸入流加工設計一個輸入模塊，向上屬模塊提供輸入信息，而這個模塊又需要兩個下屬模塊，一個為此模塊輸入信息，另一個將接收的信息轉換為上屬模塊所需的信息。如果輸入模塊還有輸入模塊時，又要重復上屬過程，若輸入模塊是物理輸入端時，則細化工作停止。

CIC取BB轉換BBCA取A轉化AAB第五十八頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

為輸出流加工設計一個輸出模塊，接收中心加工的輸出信息，而這個模塊又需要兩個下屬模塊，一個將接收的信息轉換為輸出的形式，另一個將它們輸出。如果輸出模塊還有輸出模塊時，又要重復上屬過程，若輸出模塊是物理輸出端時，則細化工作停止。COD轉換DD送EEE轉換E送FFF第五十九頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

為中心加工設計轉換模塊。

(5)進一步細化對上述采用轉換分解技術方法得到的結構圖按照設計標準進一步細化。CT處理CCDCD第六十頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計事務分析

（1）確定數據流圖的類型（2）確立流界

◆

從數據流圖中找出事務中心

◆

確定事務流

◆

確定事務路徑

1事務流P2P1P3事務中心事務路經第六十一頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

（3）進行一級分析，設計上層模塊。

事務分析的任務是從數據流圖中導出具有接受分支和發(fā)送分支的軟件結構。對事務中心設計“事務控制”模塊；對事務流設計“接受事務’’模塊；對事務路徑，設計“發(fā)送事務’’模塊。事務控制接受事務發(fā)送事務第六十二頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

(4)進行二級分解，設計中下層模塊。對于接受分支，可用類似于轉換處理型數據流圖中對輸人數據流的分析方法設計中下層模塊。對于發(fā)送分支，在發(fā)送事務模塊下為每個事務路徑設計一個事務處理模塊。這一層稱為事務層。在事務層模塊下，沿各事務路徑進行分析，進一步細化，設計動作層模塊及細節(jié)層模塊等。第六十三頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計

好的設計準則：①模塊獨立性高。②模塊規(guī)模適中。③深度、寬度適度④作用域在控制域內。⑤接口和界面簡單。⑥模塊的出口、入口為單入口、單出口。⑦功能可預測。

第六十四頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計2.詳細設計

詳細設計的任務是為軟件結構圖中的每個模塊確定實現(xiàn)算法和局部數據結構，用某種選定的表達工具表示算法和數據結構的細節(jié)。

常見設計工具有：圖形工具：程序流程圖，N-S（方框圖），PAD（問題分析圖）；表格工具：判定表；語言工具：PDL（偽碼）。

第六十五頁，共一百四十三頁，編輯于2023年，星期三2.1結構化開發(fā)方法第六十六頁，共一百四十三頁，編輯于2023年，星期三第六十七頁，共一百四十三頁，編輯于2023年，星期三第六十八頁，共一百四十三頁，編輯于2023年，星期三方框圖（N-S圖）。2.1面向過程分析與設計第六十九頁，共一百四十三頁，編輯于2023年，星期三2.1面向過程分析與設計第七十頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

面向對象方法和技術是自20世紀80年代以來逐漸形成的一種分析問題和解決問題的新方法，它的基本出發(fā)點是盡可能按照人類認識世界的方法和思維方式來分析和解決問題。面向對象方法不把程序看作是工作在數據上的一系列過程或函數的集合，而是把程序看作是相互協(xié)作而又彼此獨立的對象的集合。第七十一頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

面向對象軟件開發(fā)方法又稱為OOSD（Object-OrientedSoftwareDevelopment）。

OOSD包括面向對象分析（OOA）、面向對象設計（OOD）和面向對象程序設計（OOP）3個方面。

OOP是基礎，OOA和OOD是應用OOP的機制。所以應用OOSD時，必須使用面向對象程序設計語言。第七十二頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計2.2.1傳統(tǒng)軟件分析設計的問題

(1)傳統(tǒng)的軟件分析技術難以應對需求的不斷變化

(2)傳統(tǒng)軟件開發(fā)方法無法實現(xiàn)高效的軟件復用

(3)傳統(tǒng)軟件設計方法難以實現(xiàn)從分析到設計的直接過渡

第七十三頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計2.2.2面向對象分析與設計的主要特點

(1)按照人類習慣的思維方法，對軟件開發(fā)過程所有階段進行綜合考慮傳統(tǒng)的面向過程的設計方法以算法為核心，將數據和過程作為相互獨立的部分，程序代碼用于處理這些數據

面向對象的方法以對象為核心，強調模擬現(xiàn)實世界中的概念而不是算法，盡量用符合人類認識世界的思維方式來漸進地分析、解決問題

第七十四頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計（2）軟件生存期各階段所使用的方法、技術具有高度的連續(xù)性傳統(tǒng)的軟件開發(fā)過程把一個充滿回溯的軟件開發(fā)過程硬性地分割為幾個階段，而且各個階段所使用的模型、描述方法不相同。面向對象的方法使用噴泉模型作為其工作模型，軟件生存期各階段沒有明顯的界限，開發(fā)過程回溯重疊，使用相同的描述方法和模型，使得軟件生存期各階段所使用的方法、技術具有高度的連續(xù)性。第七十五頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計(3)軟件開發(fā)各階段有機集成，有利于系統(tǒng)的穩(wěn)定性

OOA、OOD與OOP有機地集成在一起，使開發(fā)過程始終圍繞著建立問題領域的對象(類)模型進行，且各階段解決的問題又各有側重。(4)具有良好的重用性由于對象具有的封裝性和信息隱蔽，使得對象的內部實現(xiàn)與外界隔離，具有較強的獨立性，因此，對象類提供了較理想的可重用的軟件成分。第七十六頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計2.2.3面向對象建模

面向對象分析與設計從3種角度建立模型：

1)使用對象模型描述系統(tǒng)數據結構

定義了做事情的實體

2)使用動態(tài)模型描述系統(tǒng)動態(tài)的協(xié)作及控制結構規(guī)定了什么時候做

3)使用功能模型描述系統(tǒng)功能系統(tǒng)應該“做什么”

第七十七頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計準備知識：

(1)對象。對象是人們要進行研究的任何事物，從最簡單的整數到復雜的飛機等均可看作對象，它不僅能表示具體的事物，還能表示抽象的規(guī)則、計劃或事件。

(2)對象的狀態(tài)和行為。對象具有狀態(tài)，一個對象用數據值來描述它的狀態(tài)。對象還有操作，用于改變對象的狀態(tài)，對象及其操作就是對象的行為。對象實現(xiàn)了數據和操作的結合，使數據和操作封裝于對象的統(tǒng)一體中。第七十八頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計（3）類具有相同或相似性質的對象的抽象就是類。因此，對象的抽象是類，類的具體化就是對象，也可以說類的實例是對象。類具有屬性，它是對象的狀態(tài)的抽象，用數據結構來描述類的屬性。類具有操作，它是對象的行為的抽象，用操作名和實現(xiàn)該操作的方法來描述。

第七十九頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計（4）消息和方法對象之間進行通信的結構叫做消息。在對象的操作中，當一個消息發(fā)送給某個對象時，消息包含接收對象去執(zhí)行某種操作的信息。發(fā)送一條消息至少要包括說明接受消息的對象名、發(fā)送給該對象的消息名（即對象名、方法名）。一般還要對參數加以說明，參數可以是認識該消息的對象所知道的變量名，或者是所有對象都知道的全局變量名。類中操作的實現(xiàn)過程叫做方法，一個方法有方法名、參數、方法體。第八十頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計（5）面向對象的特征封裝性：將對象的特性（屬性）和行為（方法）包裝在一起。它實現(xiàn)了信息的隱蔽作用，使我們通過類的方法來操作該類的對象，而不必關心其內部實現(xiàn)。抽象性：將具有一致的數據結構（屬性）和行為（操作）的對象抽象成類。繼承性：是子類自動共享父類數據結構和方法的機制，這是類之間的一種關系。第八十一頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

多態(tài)性：描述的是面向對象里同一方法名的多種實現(xiàn)。多態(tài)有兩類情況：一類是方法的重寫（Overriding），另一類是方法的重載（Overloading）。重寫發(fā)生在父類與子類的方法之間，重載發(fā)生在同一個類的方法之間。重寫指子類可以重寫實現(xiàn)父類中有相同的名稱和參數的方法，以屏蔽父類的調用。重載指一個類中多個同名的方法，通過具有不同的參數個數或有不同的參數類型，來完成不同的實現(xiàn)，甚至返回不同的類型。第八十二頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計2.2.3UML（統(tǒng)一建模語言）簡介

UML（UnifiedModelingLanguage）不僅統(tǒng)一了Booch方法、OMT方法、OOSE方法、OOA/OOD的表示方法，而且對其作了進一步的發(fā)展，最終統(tǒng)一為大眾接受的標準建模語言。

UML是一種定義良好、易于表達、功能強大的建模語言。它不但支持面向對象的分析與設計，還支持從需求分析開始的軟件開發(fā)全過程。第八十三頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計統(tǒng)一建模語言(UnifiedModelingLanguage，UML)是目前最流行的可視化建模語言，可以貫穿軟件開發(fā)周期中的每一個階段。

第八十四頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計1．用例圖(UseCaseDiagram)

用例圖用于需求分析階段，第一，它描述了待開發(fā)系統(tǒng)的功能需求，強調這個系統(tǒng)是什么；第二，它將系統(tǒng)看作黑盒，從外部參與者的角度來理解系統(tǒng)；第三，它驅動了需求分析之后各階段的開發(fā)工作，不僅在開發(fā)過程中保證了系統(tǒng)所有功能的實現(xiàn)，而且被用于驗證和檢測所開發(fā)系統(tǒng)是否滿足需求。用例圖的主要元素是角色(Actor)、用例(UseCase)、角色與用例間的通信角色代表觸發(fā)系統(tǒng)功能的用戶或其他系統(tǒng)用例代表具體的功能描述

第八十五頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計(1)角色（參與者）角色是系統(tǒng)外部的一個實體，它以某種方式參與用例的執(zhí)行過程。角色通過向系統(tǒng)輸入或請求輸入某些事件來觸發(fā)系統(tǒng)的執(zhí)行。角色包括人角色(HumanActor)和外部系統(tǒng)角色(SystemActor)。系統(tǒng)的用戶是人角色，用戶通過與系統(tǒng)的交互，操縱系統(tǒng)，完成所需要的工作。與本系統(tǒng)交互的外部系統(tǒng)是另一種角色，它與本系統(tǒng)相互作用，交換信息。它可以是軟件系統(tǒng)，也可以是硬件設備，例如在實時監(jiān)控系統(tǒng)中的數據采集器等。

第八十六頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

第八十七頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

（2）用例規(guī)定了系統(tǒng)或部分系統(tǒng)的行為。描述了系統(tǒng)具有的行為，但沒有規(guī)定怎樣實現(xiàn)這些行為，它是從用戶（角色）的角度來看系統(tǒng)的特定方式。第八十八頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

(3)用例間的關系①泛化關系(Generalization)（類屬關系）即用例之間的一般和特殊關系②包含關系(Include)。即源用例包含了其他用例的行為③擴展關系(Extend)

即目標用例擴充了源用例的行為第八十九頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計(4)UML用例圖第九十頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

（2）類圖(ClassDiagram)

類圖描述系統(tǒng)的靜態(tài)結構，是面向對象系統(tǒng)建模最常用的圖，它描述了類、接口及它們之間的關系。主要元素是類以及類之間的關系。

第九十一頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計類描述了一類對象的屬性和行為。

類與類之間通常有泛化(繼承)、關聯(lián)、聚合與組合、依賴等多種關系。第九十二頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

(1)泛化(繼承)

繼承是類與類之間較常見的關系，一個類(稱為子類)繼承另一個類(稱為基類)的功能，并增加它自己的新功能。

第九十三頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

(2)關聯(lián)關聯(lián)表示兩個類的對象之間存在某種語義上的聯(lián)系，是類之間的一種很弱的聯(lián)系。第九十四頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

(3)聚合與組合聚合與組合都是特殊的關聯(lián)關系，都體現(xiàn)了整體與部分的關系。聚合體現(xiàn)的是整體與部分擁有的關系即has-a的關系，此時整體與部分之間是可分離的，它們可以具有各自的生命周期，部分可以屬于多個整體對象，也可以為多個整體對象共享比如計算機與CPU、公司與員工的關系等第九十五頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計組合體現(xiàn)的是一種contains-a的關系，這種關系比聚合更強，也稱為強聚合，但此時整體與部分是不可分的，整體的生命周期結束也就意味著部分的生命周期結束，例如人和人的大腦。

UML中定義聚合和組合都使用一個帶菱形的連線表示，菱形指向具有整體性質的類，其中未填充的菱形表示聚合，填充的菱形表示組合。

第九十六頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

(4)依賴當一個類A使用到另一個類B，并且B類的變化會影響到A類，則稱A類依賴于B類。第九十七頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

（3）對象圖（ObjectDiagram）對象圖描述了某一瞬間系統(tǒng)的對象、對象的狀態(tài)及對象間的關系。對象圖可以看作是類圖的實例。對象是類的實例，對象間的連線是類之間的關聯(lián)關系的實例。

Object1Object2第九十八頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

（4）交互作用圖包括時序圖和協(xié)作圖，描述了對象間的交互作用，由對象、對象間的關系組成，并包含在對象間傳遞的消息。時序圖描述了消息的時間順序，適合于描述實時系統(tǒng)和復雜的腳本。它是一張表，對象沿X軸排列，消息按照時間順序遞增沿Y軸排序。第九十九頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

協(xié)作圖強調發(fā)送和接收消息的對象的組織結構。

協(xié)作圖和時序圖在語義上是相當的，可以彼此轉換而不損失信息。第一百頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

（5）狀態(tài)圖

狀態(tài)圖描述類的特定對象所有可能的狀態(tài)，以及事件發(fā)生時狀態(tài)的轉移條件。

第一百零一頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

（6）活動圖

主要是一個流圖，描述了從活動到活動的流。它由一系列動作組成。

第一百零二頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

交互作用圖強調從對象到對象的控制流，活動圖則強調從活動到活動的控制流。第一百零三頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

（7）組件圖組件圖描述了組件及組件間的關系。

它的用途是顯示系統(tǒng)中的軟件對其他軟件組件的依賴關系。

第一百零四頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

（8）配置圖

配置圖描述軟件系統(tǒng)如何部署到硬件環(huán)境中，反映了系統(tǒng)中軟件和硬件的物理架構，表示系統(tǒng)運行時的處理節(jié)點以及節(jié)點中組件的配置。它的用途是顯示該系統(tǒng)不同的組件將在何處物理地運行，以及將如何彼此通信。第一百零五頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

有很多CASE工具都支持UML設計，如Visio、PowerDesinger、RationalRose等。這些工具不僅提供了標準的符號來繪制UML的各類模型圖，同時也提供了很多輔助工具來輔助分析人員進行模型檢查和各類正向與逆向工程。

第一百零六頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計2.2.4面向對象分析

1．面向對象分析的基本過程（1）學習、了解原始需求目的：1）初步了解業(yè)務需求

2）找出原始需求中存在二義性、不完整、不準確的需求為需求分析打基礎（2）進一步的需求調研發(fā)現(xiàn)和改正原始陳述中的二義性和不一致性，補充遺漏的內容，從而使需求陳述更完整、更準確。

第一百零七頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計（3）需求分析

深入理解用戶需求，抽象出目標系統(tǒng)的本質屬性，并用模型準確地表示出來。

（4）建立對象模型面向對象建模得到的模型包含3類，即對象模型、動態(tài)模型、功能模型。這3類模型在不同的系統(tǒng)中的重要程度不同，但是對象模型是任何一個軟件系統(tǒng)都需要的，當涉及交互作用和時序時(如用戶界面及過程控制等)，需要使用動態(tài)模型。第一百零八頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

2．建立對象模型對象模型的建立主要是確定類、建立類之間的關聯(lián)關系、確定類的屬性等過程。

(1)確定類與對象

以自然語言書寫的需求陳述為依據，把陳述中的名詞作為類與對象的候選者，用形容詞作為確定屬性的線索，把動詞作為服務(操作)的候選者。

第一百零九頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

用這種簡單方法確定的候選者是不準確的，往往包含大量不正確的或不必要的事物，必須經過進一步的嚴格篩選，從中去掉不正確的或不必要的，僅保留確實應該記錄其信息或需要其提供服務的那些對象，篩選時主要依據下列標準：①冗余。如果兩個類表達了同樣的信息，則應該保留在此問題域中最富于描述力的名稱。②無關。僅需要把與本問題密切相關的類放進目標系統(tǒng)中，與當前要解決的問題無關的類應該刪掉。

第一百一十頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計③籠統(tǒng)。在需求陳述中常常使用一些籠統(tǒng)的名詞，如果系統(tǒng)無需處理有關它們的信息或者有更明確更具體的名詞對應它們所暗示的事務，那么就應該去掉這些籠統(tǒng)的或模糊的類。④屬性。在需求陳述中有些名詞實際上描述的是其他對象的屬性，應該把這些名詞從候選類與對象中去掉。⑤操作。在需求陳述中有時可能使用一些既可作為名詞，又可作為動詞的詞，應該慎重考慮它們在本問題中的含義，以便正確地決定把它們作為類還是作為類中定義的操作。⑥實現(xiàn)。在分析階段不應該過早地考慮怎樣實現(xiàn)目標系統(tǒng)，在分析階段過早地考慮它們反而會分散注意力，因此應該去掉僅和實現(xiàn)有關的候選類與對象。第一百一十一頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計需要不斷地和用戶、領域專家交流，反復構造模型，逐漸澄清二義性，改正錯誤，才能最終把模型建立起來

第一百一十二頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

(3)劃分主題為了降低復雜程度，在開發(fā)大型、復雜系統(tǒng)的過程中，可以把系統(tǒng)再進一步劃分成幾個不同的主題，也就是在概念上把系統(tǒng)包含的內容分解成若干范疇。應該按問題領域而不是用功能分解方法來確定主題。

(4)確定屬性通常，在需求陳述中用名詞詞組表示屬性，但是不可能僅依靠需求陳述找到所有屬性，還必須借助于領域知識和常識才能分析得出需要的屬性。應該僅考慮與具體應用直接相關的屬性，不要考慮那些超出所要解決的問題范圍的屬性。

第一百一十三頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

(5)識別繼承關系一般說來，可以使用兩種方式建立繼承(即泛化)關系：①自底向上：抽象出現(xiàn)有類的共同性質泛化出父類，這個過程實質上模擬了人類歸納思維過程。②自頂向下：把現(xiàn)有類細化成更具體的子類，這模擬了人類的演繹思維過程。從應用域中常常能明顯看出應該做的自頂向下的具體化工作。第一百一十四頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

3．建立動態(tài)模型建立動態(tài)模型基本包括：

1)編寫典型交互行為的腳本；

2)從腳本中提取出事件，確定觸發(fā)每個事件的動作對象以及接收事件的目標對象；

3)排列事件發(fā)生的次序，確定每個對象可能有的狀態(tài)及狀態(tài)間的轉換關系，并用狀態(tài)圖描繪它們；

4)比較各個對象的狀態(tài)圖，檢查它們之間的一致性，確保事件之間的匹配。第一百一十五頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

4．建立功能模型功能模型表明了系統(tǒng)中數據之間的依賴關系，以及有關的數據處理功能，它由一組數據流圖組成。數據流圖的畫法與結構化分析一樣，其中的處理功能可以用IPO圖(或表)、偽碼等多種方式進一步描述。在面向對象方法學中，數據流圖遠不如在結構分析、設計方法中那樣重要。與對象模型和動態(tài)模型比較起來，數據流圖并沒有增加新的信息，有助于軟件開發(fā)人員更深入地理解問題域，改進和完善自己的設計。第一百一十六頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

IPO指結構化設計中變換型結構的輸入（Input）、加工（Processing）、輸出（Output）。

IPO圖是對每個模塊進行詳細設計的工具，它是輸入加工輸出(INPUTPROCESSOUTPUT)圖的簡稱.

第一百一十七頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計2.2.5面向對象設計

按照面向對象方法的“噴泉模型”，軟件生命周期的各個階段交替回溯，整個生命周期的概念、屬性、描述方法具有一致性，因此從分析到設計無須表示方法的轉換，只是分析和設計的任務分工與側重不同。第一百一十八頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計面向對象分析建立的是應用領域面向對象的模型，而面向對象設計建立的是軟件系統(tǒng)的模型。與OOA的模型比較，OOD模型的抽象層次較低，但是建模的原則和方法是相同的。總體看，分析與設計本質上是一個多次反復迭代的過程，而面向對象分析與面向對象設計的界限尤其模糊。用面向對象方法設計軟件，原則上也是先進行總體設計(即系統(tǒng)設計)，然后再進行詳細設計(對象)，當然，它們之間的界限非常模糊，事實上是一個多次反復迭代的過程。

第一百一十九頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計1．面向對象設計的基本任務將分析階段所創(chuàng)建的分析模型轉換為設計模型，解決如何做的問題。面向對象分析主要考慮系統(tǒng)做什么，而不關心系統(tǒng)如何實現(xiàn)的問題。在面向對象設計需要以OOA模型為基礎，重新定義或補充一些新的類，或在原有類中補充或修改一些屬性及操作。因此，OOD的目標是產生一個滿足用戶需求的、可實現(xiàn)的OOD模型。第一百二十頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計面向對象的設計包括系統(tǒng)設計和對象設計。

(1)系統(tǒng)設計將分析模型中緊密相關的類劃分為若干子系統(tǒng)(也稱為主題)，子系統(tǒng)應該具有良好的接口，子系統(tǒng)中的類相互協(xié)作。進行系統(tǒng)設計的關鍵是子系統(tǒng)的劃分，子系統(tǒng)由它們的責任及所提供的服務來標識，在OOD中，這種服務是完成特定功能的一組操作。

第一百二十一頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

(2)對象設計為每個類的屬性和操作進行詳細設計，包括屬性和操作的數據結構及實現(xiàn)算法，以及類之間的關聯(lián)。另外，在OOA階段，將一些與具體實現(xiàn)條件密切相關的對象，例如，與圖形用戶界面(GUI)、數據管理、硬件及操作系統(tǒng)有關的對象推遲到OOD階段考慮。

第一百二十二頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

(3)設計優(yōu)化主要涉及提高效率的技術和建立良好的繼承關系的方法。提高效率的技術包括增加冗余關聯(lián)以提高訪問效率、調整查詢次序、優(yōu)化算法等技術。建立良好的繼承關系是優(yōu)化設計的重要內容，通過對繼承關系的調整實現(xiàn)。第一百二十三頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計

2．面向對象設計準則

(1)模塊化面向對象軟件開發(fā)模式很自然地支持了把系統(tǒng)分解成模塊的設計原理：對象就是模塊，是把數據結構和操作這些數據的方法緊密地結合在一起所構成的模塊。

(2)抽象面向對象方法不僅支持過程抽象，而且支持數據抽象，類實際上是一種抽象數據類型。

第一百二十四頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計(3)信息隱藏在面向對象方法中，信息隱藏通過對象的封裝性實現(xiàn)：類結構分離了接口與實現(xiàn)，從而支持了信息隱藏。對于類的用戶來說，屬性的表示方法和操作的實現(xiàn)算法都應該是隱藏的。(4)弱耦合在面向對象方法中，耦合主要指不同對象之間相互關聯(lián)的緊密程度。如果一類對象過多地依賴其他類對象來完成自己的工作，則不僅給理解、測試或修改這個類帶來很大困難，而且還將大大降低該類的可重用性和可移植性。第一百二十五頁，共一百四十三頁，編輯于2023年，星期三2.2面向對象分析與設計(5)強內聚內聚衡量一個模塊內各個元素彼此結合的緊密程度。也可以把內聚定義為：設計中使用的一個構件內的各個元素，對完成一個定義明確的目的所做出的貢獻程度。在設計時應該力求做到高內聚。(6)可重用重用有兩方面的含義：盡量使用已有的類(包括開發(fā)環(huán)境提供的類庫，及以往開發(fā)類似系統(tǒng)時創(chuàng)建的類)；如果確實需要創(chuàng)建新類，則在設計這些新類的協(xié)議時，應該考慮將來的可重復使用性。第一百二十六頁，共一百四十三頁，編輯于2023年，星期三2.3數據庫建模與設計

大多數軟件系統(tǒng)中都包含數據庫處理，軟件設計的成敗與數據庫設計息息相關。設計一個好的數據庫需要遵循軟件工程的理論和方法，采用規(guī)范的設計方法，根據用戶的需求，進行分析、歸納、抽象，最終設計出符合實際情況的數據模型，選擇一種符合要求的數據庫管理系統(tǒng)，最終實現(xiàn)對數據模型及數據的管理。第一百二十七頁，共一百四十三頁，編輯于2023年，星期三2.3數據庫建模與設計

規(guī)范的設計方法之一——新奧爾良(NewOrleans)方法把數據庫設計分成：6個階段。第一百二十八頁，共一百四十三頁，編輯于2023年，星期三2.3數據庫建模與設計

2.3.1需求分析

需求分析就是分析用戶的需要與要求，確定系統(tǒng)必須完成哪些工作，對系統(tǒng)提出完整、準確、清晰、具體的要求。確定用戶的最終需求非常困難。一方面用戶缺少計算機知識，開始時無法確定計算機究竟能為自己做什么，不能做什么，無法一下子準確地表達自己的需求，用戶所提出的需求往往不斷地變化。另一方面設計人員缺少用戶的專業(yè)知識，不易理解用戶的真正需求，甚至誤解用戶的需求。第一百二十九頁，共一百四十三頁，編輯于2023年，星期三2.3數據庫建模與設計

需求分析階段應該了解以下內容：①組織機構情況。包括部門組成情況、各部門的職責、應用程序的使用權限等，在此基礎上形成系統(tǒng)功能權限的劃分。②各部門的業(yè)務活動情況。包括各部門輸入和使用哪些數據，如何加工處理這些數據，處理數據需要什么具體的算法，產生什么信息，這些輸出信息提供到什么部門，輸出結果的格式是什么。在此基礎上形成數據流圖和數據字典。③用戶對系統(tǒng)的功能要求。在熟悉了業(yè)務活動的基礎上，協(xié)助用戶明確對系統(tǒng)的各種要求，包括信息要求、處理要求、完全性與完整性要求。第一百三十頁，共一百四十三頁，編輯于2023年，星期三2.3數據庫建模與設計

常用的調查方法有以下幾種。①親自參與業(yè)務活動，了解業(yè)務處理的基本情況②請專人介紹③與用戶交流、詢問等方式來解決存在的疑問④設計調查表請用戶填寫⑤查閱記錄。即查問與原系統(tǒng)有關的數據記錄。⑥學習文件。及時了解掌握與用戶業(yè)務相關的政策和業(yè)務規(guī)范等文件。⑦使用舊系統(tǒng)。如果用戶已經使用計算機系統(tǒng)協(xié)助業(yè)務處理，可以通過使用舊系統(tǒng)，掌握已有的需求、了解用戶變化的和新增的需求。

第一百三十一頁，共一百四十三頁，編輯于2023年，星期三2.3數據庫建模與設計

2.3.2概念結構設計概念結構獨立于數據庫邏輯結構，也獨立于支持