需求工程及需求分析課件

1、第3章 需求工程與需求分析13.1 基本的軟件需求2基本的軟件需求 軟件項目中百分之四十至百分之六十的問題都是在需求分析階段埋下的“禍根” ?？稍S多組織仍在那些基本的項目功能上采用一些不合規(guī)范的方法，這樣導致的后果便是一條鴻溝（期望差異）開發(fā)者開發(fā)的與用戶所想得到的軟件存在著巨大期望差異。3基本的軟件需求 在軟件工程中，所有的風險承擔者(stakeholder)都感興趣的就是需求分析階段。這些風險承擔者包括客戶、用戶、業(yè)務或需求分析員(負責收集客戶需求并編寫文檔，以及負責客戶與開發(fā)機構之間聯(lián)系溝通的人)、開發(fā)人員、測試人員、用戶文檔編寫者、項目管理者和客戶管理者。這部分工作若處理好了，能開發(fā)出

2、很出色的產(chǎn)品，同時會使客戶感到滿意，開發(fā)者也倍感滿足、充實。若處理不好，則會導致誤解、挫折、障礙以及潛在質量和業(yè)務價值上的威脅。因為需求分析奠定了軟件工程和項目管理的基礎。43.1.1 軟件需求的定義 用戶解決問題或達到目標所需的條件或權能（Capability）。 系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權能。 一種反映上面或所描述的條件或權能的文檔說明。53.1.1 軟件需求的定義1. 一些關于“需求”的解釋 需求的關鍵的問題是一定要編寫需求文檔。 如果只有一堆郵件、貼條、會談過幾次或一些零碎的對話，你就確信你已明白用戶的需求，那完全是自欺欺人。 許多的需求分

3、析專家給出了不同形式的需求定義，但從這些不同形式的定義不難發(fā)現(xiàn)：并沒有一個清晰、毫無二義性的“需求”術語存在，真正的“需求”實際上在人們的腦海中。任何文檔形式的需求（例如：需求規(guī)格說明）僅是一個模型，一種敘述（Lawrence 1998）。我們需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識。63.1.1 軟件需求的定義 2需求的層次 下面這些定義是需求工程領域中常見術語的定義說明。 軟件需求包括三個不同的層次業(yè)務需求、用戶需求和功能需求（包括非功能需求）。 業(yè)務需求（business requirement）反映了組織機構或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，它們在項目視圖與

4、范圍文檔中予以說明。 用戶需求（user requirement）文檔描述了用戶使用產(chǎn)品必須要完成的任務，這在使用實例（use case）文檔或方案腳本（scenario）說明中予以說明。 功能需求(functional requirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務，從而滿足了業(yè)務需求。所謂特性（feature）是指邏輯上相關的功能需求的集合，給用戶提供處理能力并滿足業(yè)務需求。 73.1.1 軟件需求的定義83.1.2 需求的開發(fā)和管理 需求中名詞術語的混淆將導致對科目（規(guī)范，discipline）叫法的不一致。一些作者把整個需求范圍稱之為“需求工程”，另

5、一些則稱之為“需求管理”。 軟件專家認為可把整個軟件需求工程研究領域劃分為需求開發(fā)和需求管理兩部分更合適：93.1.2 需求的開發(fā)和管理 需求開發(fā)可進一步分為：需求獲取(elicitation)、分析(analysis)、編寫規(guī)格說明(specification)和驗證(verification)四個階段。 需求開發(fā)活動包括以下幾個方面： 確定產(chǎn)品所期望的用戶類。 獲取每個用戶類的需求。 了解實際用戶任務和目標以及這些任務所支持的業(yè)務需求。 分析源于用戶的信息以區(qū)別用戶任務需求、功能需求、業(yè)務規(guī)則、質量屬性、建議解決方法和附加信息。103.1.2 需求的開發(fā)和管理 將系統(tǒng)級的需求分為幾個子系統(tǒng)

6、，并將需求中的一部份分配給軟件組件。 了解相關質量屬性的重要性。 商討實施優(yōu)先級的劃分。 將所收集的用戶需求編寫成規(guī)格說明和模型。 評審需求規(guī)格說明，確保對用戶需求達到共同的理解與認識，并在整個開發(fā)小組接受說明之前將問題都弄清楚。113.1.2 需求的開發(fā)和管理 需求管理需要“建立并維護在軟件工程中同客戶達成的契約”(CMU/SEI 1995)。這種契約都包含在編寫的需求規(guī)格說明與模型中。 通常的需求管理活動包括： 定義需求基線（迅速制定需求文檔的主體）。 評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。 以一種可控制的方式將需求變更融入到項目中。 使當前的項目計劃與需求一致。

7、估計變更需求所產(chǎn)生影響并在此基礎上協(xié)商新的承諾(約定)。 讓每項需求都能與其對應的設計、源代碼和測試用例聯(lián)系起來以實現(xiàn)跟蹤。 在整個項目過程中跟蹤需求狀態(tài)及其變更情況。123.1.2 需求的開發(fā)和管理需求開發(fā)和需求管理之間的區(qū)別133.1.3 需求工程的作用 1支持項目的開發(fā)。 需求工程過程是軟件開發(fā)階段的前提和基礎。 2支持測試和驗證 需求規(guī)格說明書將為項目測試和驗證提供基準，可以用來檢查設計和驗證系統(tǒng)。 3支持維護 維護階段的工作同以下幾個方面緊密聯(lián)系： 修改在測試階段中尚未檢查出來的少量殘留編碼錯誤。 軟件運行一段時間后，因環(huán)境因素的改變而產(chǎn)生的軟件的適應性維護。 用戶在軟件交付使用后又

8、重新提出擴充功能的需求時的軟件維護。 4支持項目承包商 需求的證實過程為擬構造系統(tǒng)的正確性提供了進一步的根據(jù)。 5支持管理 為了保證項目的順利進行，項目管理者必須有一個完備的項目計劃，包括開銷、交付日期、可用資源、交付條件等等。143.2 需求獲取153.2.1 需求獲取過程 需求獲取時期的主要工作： 歸納和整理用戶提出的各種問題和要求； 弄清用戶企圖通過軟件達到的目的； 借助各種工具和方法，陳述用戶提出的實際需求，并標定軟件的作用范圍。163.2.2 需求獲取方法 需求獲取方法包括兩個方面： 指導開發(fā)小組獲取用戶需求的方法框架。 支持控制此項活動進展的過程控制機制。173.2.3 當前狀況

9、誤解：由于分析員并非該應用領域的專家，使得在需求獲取時，誤解了用戶潛在的隱含假設。 交流障礙：領域專家同一個新手交談時的用詞往往并不足以解決問題。 缺乏共同語言：由于需求分析員和系統(tǒng)用戶的經(jīng)歷和教育背景不同，他們之間通常缺乏足夠的溝通。 “完整性”問題：軟件工程師希望提出系統(tǒng)需求的用戶領域專家能清晰、簡明和完備地描述出確實可行的系統(tǒng)需求，然而，所要的需求知識在其最初階段可能是模糊、不完備甚至是不正確的。 需求永遠不會穩(wěn)定：用戶對軟件的需求常常會發(fā)生變化，并且是不可預測的。 用戶意見不統(tǒng)一：大系統(tǒng)往往有各種不同的用戶，他們往往有互相沖突的需求和不同的需求優(yōu)先次序，尋求折衷是不容易的。 錯誤的要求

10、：系統(tǒng)的定購者（付錢的人）和系統(tǒng)的使用者經(jīng)常不是一個人，定購者由于受到組織或經(jīng)費的限制，提出的需求會與最終用戶的需求相沖突。 認識混淆：有時系統(tǒng)的目標和系統(tǒng)的需求會發(fā)生混淆。目標是系統(tǒng)應達到的更為一般的特征，而需求應是可測試的。18解決問題的建議 1. 了解系統(tǒng)需求 2. 市場調查 3. 訪問用戶和用戶領域專家 4. 考察現(xiàn)場19調查的方式 1. 調查提綱或調查表 2. 小型調查會議 3. 個別訪問 4. 現(xiàn)場調查 5. 資料 6. 調查工具20調查中應注意的事項 1. 不要用計算機專業(yè)術語與用戶或用戶領域專家交談 2. 不要使用“你應該”這樣的字眼 3. 始終記住自己最近一段工作中要達到的目

11、標，引導用戶說出你需要的信息 4. 要善于把用戶中職位高的人和職位低的人的談話結合起來分析213.3 需求分析任務223.3 需求分析任務 需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其它系統(tǒng)元素的接口細節(jié)，定義軟件的其它有效性需求。 分析員通過需求分析，逐步細化對軟件的要求，描述軟件要處理的數(shù)據(jù)域，并給軟件開發(fā)提供一種可轉化為數(shù)據(jù)設計、結構設計和過程設計的數(shù)據(jù)和功能表示。在軟件完成后，制定的軟件規(guī)格說明還要為評價軟件質量提供依據(jù)。233.3 需求分析任務 正確地確定對系統(tǒng)綜合要求，充分理解和表達用戶的需求。 也就是詳細定義開發(fā)軟件的功能、性能、外部接口、設計限制

12、、數(shù)據(jù)庫需求、確定硬件和軟件支持環(huán)境、輔助軟件以及將來可能提出的要求。 通過結構分析的方法對系統(tǒng)進行分解，以確定軟件系統(tǒng)的主要成分或軟件系統(tǒng)的構成。243.3 需求分析任務 是對以上已進行的兩項工作進行描述，以形成需求文檔，也就是編制“需求規(guī)格說明書”。它應明確地定義要開發(fā)軟件的需求；系統(tǒng)的構成及有關接口。 需求規(guī)格說明書的作用在于： 提供一個用戶和開發(fā)者對開發(fā)軟件的共同的理解； 相當于用戶和開發(fā)單位之間的一份技術合同； 是今后各階段設計的基本依據(jù)； 是今后驗收測試階段對軟件進行確認和驗收的基準。253.3 需求分析任務 編寫用戶手冊概要，迫使分析員從用戶的角度看待軟件，及早考慮用戶界面工作，

13、此時編寫的重點在系統(tǒng)輸入和輸出。 把整個軟件系統(tǒng)分解為若干個子系統(tǒng)或軟件成分(如軟件包)，把整個軟件的外部功能分配給軟件系統(tǒng)的各功能成分，并詳細地定義每個軟件成分的外部功能以及它們間的接口。 編寫驗收計劃，作為今后驗收測試的依據(jù)。 修正可行性研究階段所制訂的軟件項目開發(fā)計劃。由于在需求分析過程中對將要開發(fā)的系統(tǒng)有了更深入的了解，所以可以更準確地估計開發(fā)成本、進度和資源需求。有必要對原計劃作出適當修正。263.4 需求分析過程273.4.1 功能性需求 功能性需求包括： 1功能需求 例舉出開發(fā)軟件在職能上應做什么，這是最主要的需求。 2性能需求 給出所開發(fā)軟件的技術性能指標，包括存儲容量限制、運

14、行時間限制、安全保密性等。 3環(huán)境需求 軟件系統(tǒng)運行時多所處的環(huán)境要求。 4可靠性需求 各種軟件在運行時，失敗的影響各不相同，在需求分析時，應對所開發(fā)的軟件在投入運行后不發(fā)生故障的概率，按實際的運行環(huán)境提出的要求。283.4.1 功能性需求 5安全保密要求 把軟件運行的安全需求恰當?shù)刈龀鲆?guī)定，以便對所開發(fā)的軟件給予特殊的設計，使其在運行中其安全保密方面的性能得到必要的保證。 6用戶界面需求 軟件與用戶界面的友好性是用戶能夠方便有效、愉快地使用該軟件的關鍵之一。 7資源使用需求 開發(fā)軟件運行時所需的數(shù)據(jù)、軟件、內(nèi)存空間等各項資源。 8軟件成本消耗與開發(fā)進度需求 軟件項目立項后，要根據(jù)合同規(guī)定，對

15、軟件開發(fā)的進度和各項步驟的費用提出要求，作為開發(fā)管理的依據(jù)。 9預先估計系統(tǒng)可能達到的目標 在開發(fā)過程中可對系統(tǒng)將來可能的擴充與修改做準備。29【例1】假設需要制造一個帶有四個按鈕和兩個燈泡的盒子并具有以下功能： 有四個按鈕輸入，分別稱為B1，B2，B3和B4； 有兩個燈泡作為輸出，分別稱為L1和L2； B1是打開電源的按鈕； B4是關閉電源的按鈕； B2和B3 是操作按鈕； 在B1被按下后及B4被按下前，系統(tǒng)應稱為電源打開狀態(tài)； 在B4被按下后及B1被按下前，系統(tǒng)應稱為電源關閉狀態(tài)； 在電源關閉狀態(tài)下，B2和B3按鈕不起作用； 在電源關閉狀態(tài)下，燈應不亮； 從最近一次電源打開狀態(tài)算起，如果B

16、2被按下的次數(shù)比B3被按下的次數(shù)多，L1亮，否則L2亮。 任何時候都不能有一個以上的燈泡亮； 如果其中的一個燈泡出現(xiàn)故障，另一個燈泡應以2秒鐘的間隔閃爍，而不管B2和B3的操作過程。當B4按下時，閃爍停止；當B1被按下時，閃爍重新開始。當故障被排除后閃爍停止，系統(tǒng)恢復正常狀態(tài)。30疑問？ 1. 對于在燈泡出現(xiàn)故障時是否要記錄下B2和B3的操作過程 2. 系統(tǒng)記錄或不記錄B2和B3的操作，對于故障排除后系統(tǒng)的反應如何313.4.2 非功能性需求 非功能性需求即為軟件的“約束”:非功能性需求過程需求產(chǎn)品需求外部需求交付需求實現(xiàn)方法需求標準需求可用性需求效用需求可靠性需求可移植性需求可重復需求安全保

17、密性需求性能需求應用需求法規(guī)需求費用需求互操作需求323.4.3 需求分析文檔 1需求規(guī)格說明書的作用 為用戶、分析人員和軟件設計人員之間的理解和交流提供了方便； 支持目標軟件系統(tǒng)的確認； 起到控制系統(tǒng)演進的作用。 2什么樣人閱讀需求規(guī)格說明書 必須閱讀需求規(guī)格說明書的是各種背景和技術能力都不同的人：客戶和使用者，分析人，設計師和工程師，項目管理者等。333.4.3 需求分析文檔3需求規(guī)格說明書編寫分類 按方法分類：形式化方法和非形式化方法非形式化的需求規(guī)格說明書是用自然語言寫的，可以用圖表和其 他符號幫助理解，也可以用標準化的格式來編制。形式化的需求規(guī)格說明書是用完全精確的語法和語義來表達。

18、半形式化的需求規(guī)格說明書也很有用。它采用了一些符號，但對這些符號并沒有給予精確的定義。 按文檔內(nèi)容的性質分類：操作性和說明性操作性的需求規(guī)格說明書通過說明所要求的行為來描述要求哪種系統(tǒng)，通常提供一個系統(tǒng)模型作為模擬系統(tǒng)行為的抽象裝置。說明性的需求規(guī)格說明書用純粹的說明方式來描述系統(tǒng)的特性。343.4.3 需求分析文檔 4需求規(guī)格說明書主要內(nèi)容： 概述。從系統(tǒng)的角度描述軟件的目標和任務。 數(shù)據(jù)描述 數(shù)據(jù)流圖 數(shù)據(jù)字典 系統(tǒng)接口說明 內(nèi)部接口說明 功能描述 功能 處理 設計的限制353.4.3 需求分析文檔 性能描述 性能指標 測試種類 預期的軟件響應性能 其它 參考文獻目錄 附錄363.5 驗證

19、373.5.1 需求說明的特征 1. 完整性 每一項需求都必須將所要實現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設計和實現(xiàn)這些功能所需的所有必要信息。 2. 正確性 每一項需求都必須準確地陳述其要開發(fā)的功能。做出正確判斷的參考是需求的來源，如用戶或高層的系統(tǒng)需求規(guī)格說明。若軟件需求與對應的系統(tǒng)需求相抵觸則是不正確的。只有用戶代表才能確定用戶需求的正確性，這就是一定要有用戶的積極參與的原因。沒有用戶參與的需求評審將導致此類說法：“那些毫無意義，這些才很可能是他們所要想的?！逼鋵嵾@完全是評審者憑空猜測。383.5.1 需求說明的特征 3. 可行性 每一項需求都必須是在已知系統(tǒng)和環(huán)境的權能和限制范圍內(nèi)可以實

20、施的。為避免不可行的需求，最好在獲?。╡licitation）需求(收集需求)過程中始終有一位軟件工程小組的組員與需求分析人員或考慮市場的人員在一起工作，由他負責檢查技術可行性。 4. 必要性 每一項需求都應把客戶真正所需要的和最終系統(tǒng)所需遵從的標準記錄下來?！氨匾浴币部梢岳斫鉃槊宽椥枨蠖际怯脕硎跈嗄憔帉懳臋n的“根源”。要使每項需求都能回溯至某項客戶的輸入，如使用實例或別的來源。393.5.1 需求說明的特征 5. 可修改性 在必要時或為維護每一需求變更歷史記錄時，應該修訂SRS。這就要求每項需求要獨立標出，并與別的需求區(qū)別開來，從而無二義性。每項需求只應在SRS中出現(xiàn)一次。這樣更改時易于保

21、持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明更容易修改。 6. 可跟蹤性 應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好（fine-grained）的方式編寫并單獨標明，而不是大段大段的敘述。403.5.1 需求說明的特征 7. 劃分優(yōu)先級 給每項需求、特性或使用實例分配一個實施優(yōu)先級以指明它在特定產(chǎn)品中所占的分量。如果把所有的需求都看作同樣重要，那么項目管理者在開發(fā)或節(jié)省預算或調度中就喪失控制自由度。 8. 無二義性 對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋，由于自然語言極易導致二義性，

22、所以盡量把每項需求用簡潔明了的用戶性的語言表達出來。避免二義性的有效方法包括對需 求文檔的正規(guī)審查，編寫測試用例，開發(fā)原型以及設計特定的方案腳本。 9. 可驗證性 檢查一下每項需求是否能通過設計測試用例或其它的驗證方法，如用演示、檢測等來確定產(chǎn)品是否確實按需求實現(xiàn)了。如果需求不可驗證，則確定其實施是否正確就成為主觀臆斷，而非客觀分析了。一份前后矛盾，不可行或有二義性的需求也是不可驗證的。413.6 軟件原型系統(tǒng)開發(fā)42傳統(tǒng)模型的工作特點 傳統(tǒng)軟件生存期模型的典型代表是“瀑布模型”。這種模型將軟件生存期劃分為若干階段，根據(jù)不同階段的工作特點，運用不同的方法、技術和工具來完成該階段的任務。 傳統(tǒng)思

23、想之所以強調每一階段的嚴格性，尤其是開發(fā)初期要有良好的軟件說明，主要是源于過去軟件開發(fā)的經(jīng)驗教訓，即在開發(fā)的后期或運行維護期間，修改不完善的規(guī)格說明要付出巨大的代價。 43什么是原型系統(tǒng)開發(fā) 建立系統(tǒng)模型以后，還要進行檢查。除了靜態(tài)檢查外，系統(tǒng)描述可以部分地模擬執(zhí)行，將執(zhí)行情況與對外部現(xiàn)實世界系統(tǒng)觀察得到的系統(tǒng)跟蹤信息進行對照，檢查模型是否符合要求。這種建立系統(tǒng)模型并模擬執(zhí)行和檢查的辦法叫做系統(tǒng)原型開發(fā)。 44軟件系統(tǒng)的快速原型的概念的形成 在實際工作中，特別是對于一些大型的軟件項目，在開發(fā)的早期用戶往往對系統(tǒng)只有一個模糊的想法，很難完全準確地表達對系統(tǒng)的全面要求，軟件人員對于要解決的應用問題

24、認識更是模糊不清。 隨著開發(fā)工作向前推進，用戶可能產(chǎn)生新的要求，或因環(huán)境變化，要求系統(tǒng)也隨之變化；開發(fā)者又可能在設計與實現(xiàn)的過程中遇到一些沒有預料到的困難，需要以改變需求來解脫困境。453.6.1 軟件原型化方法概述 通常，原型是指模擬某種產(chǎn)品的原始模型。在軟件開發(fā)過程中，原型是軟件一個早期可運行的版本，它反映最終系統(tǒng)的部分重要特性。 系統(tǒng)原型是軟件系統(tǒng)的初始版本，它可用來展示一些概念，給出設計選擇、發(fā)現(xiàn)問題和可能的解決方案。其目的就是為了有效的控制開發(fā)成本，使開發(fā)人員可以較早地在原型系統(tǒng)上驗證自己的設計。46軟件原型支持需求工程過程的活動 1.需求的導出 系統(tǒng)原型允許用戶在上面實驗，以便了解

25、系統(tǒng)如何支持他們的工作的。在這個過程中，用戶可能產(chǎn)生有關需求的許多新的想法，同時發(fā)現(xiàn)系統(tǒng)的優(yōu)點和不足，進而提出新的系統(tǒng)需求。 2.需求的有效性驗證 原型系統(tǒng)可以暴露出錯誤和遺漏的東西。一個經(jīng)過描述的功能可能是很有用且已經(jīng)是定義了的，但是，當這個功能模塊與其他模塊一起工作時，用戶可能發(fā)現(xiàn)他們最初的想法是錯誤的或是不完善的，必須修改系統(tǒng)描述以反映對需求的新的理解。47系統(tǒng)原型開發(fā)的優(yōu)點 1.開發(fā)人員和用戶之間的理解偏差在功能展示顯露出來。 2.開發(fā)小組可能會在原型設計中發(fā)現(xiàn)需求的不完善和不一致。 3.可以迅速展示一個應用系統(tǒng)對管理的可行性和作用。 4.原型可以用作書寫產(chǎn)量-質量系統(tǒng)描述的基礎。 5

26、.原型可支持用戶的訓練和系統(tǒng)的測試。48原型開發(fā)的過程模型49研究發(fā)現(xiàn)系統(tǒng)原型開發(fā)的其它優(yōu)點 Gordon和Bieman經(jīng)過研究發(fā)現(xiàn)，在軟件過程中使用原型還具有如下的優(yōu)點： 1.提高了系統(tǒng)的實用性。 2.使系統(tǒng)與用戶需求更貼近。 3.提高了系統(tǒng)的設計質量。 4.提高了系統(tǒng)的可維護性。 5.減少了開發(fā)的投入。 研究發(fā)現(xiàn)，用原型法來提高系統(tǒng)的實用性和更好地滿足用戶需求并不一定意味著開發(fā)成本提高。503.6.2 軟件過程中的原型開發(fā) 原型開發(fā)的種類有兩種： 1.進化式原型 采用進化式的系統(tǒng)開發(fā)方法，就是在系統(tǒng)尚未完善的時候就呈現(xiàn)給用戶，邊修改邊完善，在完善過程中逐漸地把需求弄明白。 2.拋棄式原型

27、采用原型開發(fā)方法進行需求分析和有效性驗證，評估一結束，就拋棄掉原型，重建一個完整的系統(tǒng)。51兩點重要區(qū)別 1.進化式原型的目標是給用戶一個實用的系統(tǒng)。原型開發(fā)必須從對用戶需求把握最準的部分做起，最優(yōu)處理這部分。而對用戶需求把握程度較差的部分和模糊的需求安排得稍后一些，可以在用戶明確要求后再處理。 2.拋棄式原型開發(fā)的目標是驗證和導出需求。此時應從理解得不夠好的那部分需求開始實現(xiàn)，因為要從目標中發(fā)現(xiàn)問題，對明確的需求就沒必要去做原型。52進化式原型開發(fā) 進化式原型開發(fā)的思路是：先給出一個系統(tǒng)的最初實現(xiàn)，讓用戶去使用和評論，再不斷進行細化和完善，經(jīng)過多個這樣的反復過程后形成最后完善的應用系統(tǒng)。 進

28、化式開發(fā)已經(jīng)成為快速應用開發(fā)(RAD)和聯(lián)合應用開發(fā)(JAD)技術中的一部分,已成為一個軟件開發(fā)的主流技術。53進化式原型開發(fā)54進化式原型開發(fā)方法的優(yōu)勢 1.加快系統(tǒng)交付的進度 現(xiàn)在的商業(yè)節(jié)奏加快意味著軟件支持能否快速到位是最根本的。在某些情況下，快速交貨就比提供完備功能或保證長期可維護性更為重要。 2.用戶的參與 用戶在軟件開發(fā)過程中的介入不僅僅意味著系統(tǒng)可以更好地理解軟件需求，還意味著可以使用戶逐漸喜歡系統(tǒng)，在工作中依賴它。55進化式原型開法與快速開發(fā)方法的共同基本性質 1.描述、設計和實現(xiàn)三個過程是交叉進行的 ，沒有詳細的系統(tǒng)描述，設計文檔一般都依賴于開發(fā)系統(tǒng)所使用的工具，用戶需求文檔

29、只描述系統(tǒng)的最重要的特征。 2.系統(tǒng)是逐漸增進的。在每一次增進過程中，最終用戶和其他系統(tǒng)項目的相關人員都參與到設計和評估中來。他們可能提出對系統(tǒng)改進的意見。新的需求又會在隨后的版本中被實現(xiàn)。 3.采用了快速開發(fā)技術。 4.系統(tǒng)用戶界面都是交互式開發(fā)系統(tǒng)來實現(xiàn)的。56進化式原型開發(fā)方法應注意的問題 1.管理問題 大型系統(tǒng)軟件管理機構建立起來以處理軟件過程模型。軟件過程模型定期產(chǎn)生可交付的文檔來評估項目進展的情況。原型的開發(fā)太快，以致產(chǎn)生大量的系統(tǒng)文檔。 專業(yè)技術技能不可能應用到每個開發(fā)的團隊。 2.維護問題 連續(xù)不斷地對原型的修改很可能導致系統(tǒng)的崩潰。 如果快速原型開發(fā)中使用了某項專門的技術，有

30、可能在以后尋找具有相關知識的人來維護系統(tǒng)變得十分困難。 3.契約問題 客戶和軟件開發(fā)商之間正規(guī)的契約模型是基于系統(tǒng)描述的。57增量開發(fā)方法 該開發(fā)方法避免了進化式原型開發(fā)中的經(jīng)常性變更問題。即首先建立一個總的框架，以后就以該框架結構為基礎進行開發(fā)。 在增量開發(fā)方法中，必須給出每一部分的需求和文檔。使得用戶的意見能及時地反饋，以減少錯誤的出現(xiàn)。58增量開發(fā)方法59拋棄式原型開發(fā) 拋棄式原型開發(fā)的根本作用是弄清楚需求和為管理人員評估過程風險提供額外的信息。 在拋棄式原型開發(fā)中，我們只注重其功能，而忽略其質量標準和性能指標，使這些功能經(jīng)過原型設計而得到深刻理解。 經(jīng)過評估，原型被拋棄，不再作為系統(tǒng)開

31、發(fā)的基礎。其原型開發(fā)和最終系統(tǒng)開發(fā)使用的語言也往往不一樣。60拋棄式原型開發(fā)61拋棄式原型方法存在以下問題 1. 為了盡快拿出原型，系統(tǒng)可能做了許多簡化，因而不可避免要遺漏一些重要特性。 2.在客戶和承包商之間沒有一個能寫進合同的對于原型實現(xiàn)的合法規(guī)定。 3.非功能需求，若可靠性、安全性，在原型實現(xiàn)中不會得到充分反映。623.6.3 快速原型技術 快速原型技術強調的是交付的速度，而非系統(tǒng)的性能、可維護性和可靠性。 目前，有三種較實用的快速原型技術： 1.動態(tài)高級語言開發(fā)。 2.數(shù)據(jù)庫編程。 3.組件和應用集成。63快速原型技術64使用動態(tài)高級語言的開發(fā) 動態(tài)高級語言開發(fā)是一種包含運行時數(shù)據(jù)管理

32、強大功能的編程語言。 每當選擇一種語言時，需回答以下問題： 1.問題的應用領域是什么？ 2.需要什么樣的用戶交互？ 3.語言提供的支撐環(huán)境如何？ 動態(tài)的高級語言可以混合使用以構件系統(tǒng)原型。65數(shù)據(jù)庫程序設計 1.交互式表格定義 開發(fā)者定義要顯示的各個域及其位置。 2.表格之間的關聯(lián) 開發(fā)者定義某個特定的輸入將導致后續(xù)的表格顯示。 3.域驗證 開發(fā)者定義每個域輸入值的允許范圍。66組件和應用集成 如果系統(tǒng)中許多部分都可以復用而且不需重新進行設計和實現(xiàn)，那么系統(tǒng)開發(fā)的時間就會縮短。 利用可復用組件在系統(tǒng)描述中說明哪些可復用組件是可再利用的。67原型開發(fā)的兩個層次實現(xiàn) 1. 應用層 整個應用系統(tǒng)與原

33、型結合在一起，功能模塊可以共享。 2. 組件層 單個組件集成進標準的框架從而完成系統(tǒng)的構造。 68組件和應用集成優(yōu)勢 許多原型中的功能模塊可以以極低的成本來實現(xiàn)，如果原型用戶對這些較熟悉，就不需花費額外的時間去學習這些功能。693.6.4 軟件復用可復用的軟件與快速構造原型關系很密切。一堆可復用的模塊單獨看可能是無用的，但快速構造的原型系統(tǒng)就是靠它們連接起來而得到的。對建立軟件目標系統(tǒng)而言，復用就是利用早先開發(fā)的對建立新系統(tǒng)有用的信息來生產(chǎn)新系統(tǒng)。它是一項活動，而不是一個對象。 70軟件復用的條件必須有簡單而清晰的界面；它們應當有高自包含性，即盡量不依賴其他模塊或數(shù)據(jù)結構；它們應具有一些通用的

34、功能。當然，還應有好的文檔，所有模塊的接口、功能和錯誤條件描述應遵守一定的規(guī)范。 71軟件復用的范圍1) 復用數(shù)據(jù)：指程序不做任何修改，甚至輸入輸出數(shù)據(jù)的格式也無需改動，就可以從一個環(huán)境移到另一個環(huán)境中使用。 2) 復用模塊：早期可復用模塊的概念是指單個函數(shù)，它們不需要逐行編碼就可以連接到一個程序中去 。3) 復用結構：有效的復用應有一個結構上的考慮，而不僅是將模塊連接在一起。 4) 復用設計：軟件設計與實現(xiàn)是兩個不同的階段。若對于同一個設計，可以采用不同的實現(xiàn)方法，則這樣的設計就是可復用的。 5) 復用規(guī)格說明：在基本需求不改變，或某一新問題與過去的某一軟件在某個抽象層次上屬于同一類的情況下

35、，原規(guī)格說明仍可使用或參照使用。 72軟件復用技術軟件復用技術可分為兩大類：合成技術和生成技術。1) 合成技術：在合成技術中，構件(Building Blocks)是復用的基石。構件方法以抽象數(shù)據(jù)類型為理論基礎，借用了硬件中集成電路芯片的思想：即將功能細節(jié)與數(shù)據(jù)結構隱藏封裝在構件內(nèi)部，有著精心設計的接口。構件在開發(fā)中像芯片那樣使用，它們可以組裝成更大的構件。構件可以是某一函數(shù)、過程、子程序、數(shù)據(jù)類型、算法等可復用軟件成份的抽象，利用構件來構造軟件系統(tǒng)，有較高的生產(chǎn)率和較短的開發(fā)周期。 73三種方式將構件合成更大的構件 連接。通常，標準函數(shù)庫中的標準函數(shù)是靠編譯和連接程序與其他模塊一起合成系統(tǒng)的

36、 消息傳遞和繼承。例如smalltalk面向對象的程序設計體系結構，就是通過消息傳遞和繼承機制把對象類與其相關的其他對象類聯(lián)系起來合成一個系統(tǒng)的。 管道機制。例如，UNIX中用管道(pipe)連接shell命令，使前一命令的輸出成為后一命令的輸入，用管道機制把多個shell命令連接在一起完成一個更復雜的功能。74軟件復用技術2) 生成技術：生成技術利用可復用的模式(Patterns)，通過生成程序產(chǎn)生一個新的程序或程序段，產(chǎn)生的程序可以看成是模式的實例?？蓮陀玫哪Ｊ接袃煞N不同的形式：代碼模式和規(guī)則模式。前者的例子是應用生成器，可復用的代碼模式就存在于生成器自身。通過特定的參數(shù)替換，生成抽象軟件

37、模塊的具體實體。后者的例子是變換系統(tǒng)，它利用變換規(guī)則集合。其變換方法中通常采用超高級的規(guī)格說明語言，形式化地給出軟件的需求規(guī)格說明，利用程序變換系統(tǒng)(有時要經(jīng)過一系列變換)，把用超高級規(guī)格說明語言編寫的程序轉化成某種可執(zhí)行語言的程序。這種超高級語言抽象能力高，邏輯性強，形式化好，便于使用軟件者維護。75兩種復用技術比較構件方法支持自底向上的軟件開發(fā)方法，應當具有硬軟件獨立性、可讀性、可理解性、正確性和可修改性。變換方法側重于程序的推導方式、推理規(guī)則，支持自頂向下的軟件開發(fā)技術。由于它的形式化程度高，抽象性強，一般軟件開發(fā)者不易掌握，在描述某些實際問題時也有困難。另外，經(jīng)過多次變換得到的可執(zhí)行程

38、序的效率較低，在時間和存儲空間方面的需求較高，這都是需要解決的問題?？梢詫⑦@兩種方法結合起來使用，取長補短，再吸收人工智能的研究成果，以知識庫為輔助工具，可促進復用技術的成熟。 763.7 結構化分析方法77結構化分析方法(Strutured Analisys)結構化分析是面向數(shù)據(jù)流進行分析的方法，結構化分析方法適用與數(shù)據(jù)處理類型軟件的需求分析。結構化分析方法是利用抽象模型的概念，按照軟件內(nèi)部數(shù)據(jù)傳遞，變換的關系，自頂向下，逐步分解，直到找到滿足功能要求的所有可實現(xiàn)的軟件為止。結構化方法使用以下幾個工具：數(shù)據(jù)流圖，數(shù)據(jù)字典，結構化語言，判定樹和判定表等。783.7.1 系統(tǒng)流程圖 1 符號 當

39、以概括的方式抽象地描繪一個物理系統(tǒng)時，僅僅使用圖3.7.1中列出的基本符號就夠了，其中每個符號表示系統(tǒng)中的一個部件。 當需要更具體地描繪一個物理系統(tǒng)時還需要使用圖3.7.2中列出的系統(tǒng)符號，利用這些符號可以把一個廣義的輸入輸出操作具體化為讀寫存儲在特殊設備上的文件（或數(shù)據(jù)庫），把一般的處理具體化為特定的程序或手工操作等等。 79例子某裝配廠有一座存放零件的倉庫，倉庫中現(xiàn)有的各種零件的數(shù)量以及每種零件的庫存量臨界值等數(shù)據(jù)記錄在庫存清單主文件中。當倉庫中零件數(shù)量有變化時，應該及時修改庫存清單主文件，如果那種零件的庫存量少于它的庫存量臨界值，則應該報告給采購部門以便訂貨，規(guī)定每天向采購部門送一次訂貨

40、報告。該裝配廠使用一臺小型計算機處理更新庫存清單主文件和產(chǎn)生訂貨報告的任務。零件庫存量的每一次變化稱為一個事務，由放在倉庫中的CRT終端輸入到計算機中；系統(tǒng)中的庫存清單程序對事務進行處理，更新存儲在磁盤上的庫存清單主文件，并且把必要的訂貨信息寫在磁帶上。最后，每天由報告生成程序讀一次磁帶，并且打印出訂貨報告。 80例子813.7.2 數(shù)據(jù)流圖(DFD,Data Flow Diagram) 數(shù)據(jù)流圖描繪系統(tǒng)的邏輯模型，圖中沒有任何具體的物理元素，只是描繪信息在系統(tǒng)中流動和處理的情況。因為數(shù)據(jù)流圖是邏輯系統(tǒng)的圖形表示，即使不是專業(yè)的計算機技術人員也容易理解，所以是極好的通信工具。 823.7.2

41、數(shù)據(jù)流圖(DFD,Data Flow Diagram) 1. 符號 數(shù)據(jù)流圖有四種基本符號：正方形（或立方體）表示數(shù)據(jù)的源點或終點；圓角矩形（或圓形）代表變換數(shù)據(jù)的處理；開口矩形（或兩條平行橫線）代表數(shù)據(jù)存儲；箭頭表示數(shù)據(jù)流，即特定數(shù)據(jù)的流動方向。注意，數(shù)據(jù)流與程序流程圖中用箭頭表示的控制流有本質不同，千萬不要混淆。熟悉程序流程圖的初學者在畫數(shù)據(jù)流圖時，往往試圖在數(shù)據(jù)流圖中表現(xiàn)分支條件或循環(huán)，殊不知這樣做將造成混亂，畫不出正確的數(shù)據(jù)流圖。在數(shù)據(jù)流圖中應該描繪所有可能的數(shù)據(jù)流向，而不應該描繪出現(xiàn)某個數(shù)據(jù)流的條件。(圖示)83數(shù)據(jù)流圖性質 數(shù)據(jù)流圖中的箭頭僅能表示在系統(tǒng)中流動的數(shù)據(jù)； 與程序流程圖

42、不同，DFD不能表示程序的控制結構； DFD表現(xiàn)的范圍具有很大的靈活性。84例1假設一家工廠的采購部每天需要一張訂貨報表，報表按零件編號排序，表中列出所有需要再次訂貨的零件。對于每個需要再次訂貨的零件應該列出下述數(shù)據(jù)：零件編號，零件名稱，訂貨數(shù)量，目前價格，主要供應者，次要供應者。零件入庫或出庫稱為事務，通過放在倉庫中的CRT終端把事務報告給訂貨系統(tǒng)。當某種零件的庫存數(shù)量少于庫存量臨界值時就應該再次訂貨。 (勾畫分析表) 85例2以到銀行取款為例。某年某日儲戶到銀行把存折和取款單一并交給銀行出納員檢驗。出納員核對賬目，一旦發(fā)現(xiàn)存折有效性問題、取款單填寫問題或是存折、帳卡與取款單不符等問題時均應

43、報告儲戶。在檢驗通過后，出納員將取款信息登錄在存折和帳卡上，并通知付款。根據(jù)付款通知給儲戶付款。到此，整個取款過程完成。首先從問題描述中提取數(shù)據(jù)流圖的四種成分。數(shù)據(jù)的源點：儲戶、日歷（隱含）。數(shù)據(jù)的終點：儲戶處理有：檢驗、登錄、付款。數(shù)據(jù)存儲：存折、帳卡數(shù)據(jù)流：儲戶提交的存折和取款單、帳卡提供的帳卡信息，檢驗通不過時出納員告知的檢查出的問題、通過檢驗后的取款信息、付款通知、付給儲戶的現(xiàn)款以及日歷提供的提款時間信息86例2873.7.2 數(shù)據(jù)流圖(DFD,Data Flow Diagram) 2. 命名 數(shù)據(jù)流圖中每個成分的命名是否恰當，直接影響數(shù)據(jù)流圖的可理解性。因此，給這些成分起名字時應該仔

44、細推敲。下面講述在命名時應注意的問題： 為數(shù)據(jù)流（或數(shù)據(jù)存儲）命名 名字應代表整個數(shù)據(jù)流（或數(shù)據(jù)存儲）的內(nèi)容，而不是僅僅反映它的某些成分。 不要使用空洞的、缺乏具體含義的名字（如“數(shù)據(jù)”、“信息”、“輸入”之類）。 如果在為某個數(shù)據(jù)流（或數(shù)據(jù)存儲）起名字時遇到了困難，則很可能是因為對數(shù)據(jù)流圖分解不恰當造成的，應該試試重新分解，看是否能克服這個困難。883.7.2 數(shù)據(jù)流圖(DFD,Data Flow Diagram) 為處理命名 通常先為數(shù)據(jù)流命名，然后再為與之相關聯(lián)的處理命名。這樣命名比較容易，而且體現(xiàn)了人類習慣的“由表及里”的思考過程。 名字應該反映整個處理的功能，而不是它的一部分功能。

45、名字最好由一個具體的及物動詞，加上一個具體的賓語組成。應該盡量避免使用“加工”、“處理”等空洞籠統(tǒng)的動詞作名字。 通常名字中僅包括一個動詞，如果必須用兩個動詞才能描述整個處理的功能，則把這個處理再分解成兩個處理可能更恰當些。 如果在為某個處理命名時遇到困難，則很可能是發(fā)現(xiàn)了分解不當?shù)嫩E象，應考慮重新分解。893.7.2 數(shù)據(jù)流圖(DFD,Data Flow Diagram) 3. 用途 畫數(shù)據(jù)流圖的基本目的是利用它作為交流信息的工具。分析員把他對現(xiàn)有系統(tǒng)的認識或對目標系統(tǒng)的設想用數(shù)據(jù)流圖描繪出來，供有關人員審查確認。由于在數(shù)據(jù)流圖中通常僅僅使用四種基本符號，而且不包含任何有關物理實現(xiàn)的細節(jié)，因

46、此，絕大多數(shù)用戶都可以理解和評價它。從數(shù)據(jù)流圖的基本目標出發(fā)，可以考慮在一張數(shù)據(jù)流圖中包含多少個元素合適的問題。一些調查研究表明，如果一張數(shù)據(jù)流圖中包含的處理多于59個，人們就難于領會它的含義了。因此數(shù)據(jù)流圖應該分層，并且在把功能級數(shù)據(jù)流圖細化后得到的處理超過9個時，應該采用畫分圖的辦法，也就是把每個主要功能都細化為一張數(shù)據(jù)流分圖，而原有的功能級數(shù)據(jù)流圖用來描繪系統(tǒng)的整體邏輯概貌。90分層數(shù)據(jù)流圖1. 概念 為有效控制復雜度，在產(chǎn)生數(shù)據(jù)流圖時采用分層技術。2. 組成 把一個系統(tǒng)分為頂層DFD、中間層DFD和底層DFD。91分層數(shù)據(jù)流圖92分層數(shù)據(jù)流圖3. 分層原則父圖與子圖關系編號平衡規(guī)則文件

47、局部性分解程度933.7.3 數(shù)據(jù)字典(DD,Data Dictionary)數(shù)據(jù)字典是關于數(shù)據(jù)的信息的集合，也就是對數(shù)據(jù)流圖中包含的所有元素的定義的集合。任何字典最主要的用途都是供人查閱對不了解的條目的解釋，數(shù)據(jù)字典的作用也正是在軟件分析和設計的過程中給人提供關于數(shù)據(jù)的描述信息。數(shù)據(jù)流圖和數(shù)據(jù)字典共同構成系統(tǒng)的邏輯模型，沒有數(shù)據(jù)字典數(shù)，數(shù)據(jù)流圖就不嚴格，然而沒有數(shù)據(jù)流因數(shù)據(jù)字典也難于發(fā)揮作用。只有數(shù)據(jù)流圖和對數(shù)據(jù)流圖中每個元素的精確定義放在一起，才能共同構成系統(tǒng)的規(guī)格說明。數(shù)據(jù)字典中所有的定義應是嚴密的、精確的，不可有半點含混，不可有二義性。943.7.3 數(shù)據(jù)字典(DD,Data Dict

48、ionary) 1. 數(shù)據(jù)字典的定義 對在數(shù)據(jù)流圖中每一個命名的圖形元素均給予定義，其內(nèi)容有圖形元素的名字、別名或編號、分類、描述、定義、位置等。 數(shù)據(jù)流詞條描述 數(shù)據(jù)流是數(shù)據(jù)結構在系統(tǒng)內(nèi)傳播的路徑。一個數(shù)據(jù)流詞條有以下幾項內(nèi)容。 數(shù)據(jù)元素詞條描述 圖中的每一個數(shù)據(jù)結構都是由數(shù)據(jù)元素構成的，數(shù)據(jù)元素是數(shù)據(jù)處理中最小的，不可再分的單位，它直接反映事物的某一特征。 數(shù)據(jù)文件詞條描述 數(shù)據(jù)文件是數(shù)據(jù)結構保存的地方。一個數(shù)據(jù)文件詞條有以下幾項內(nèi)容 加工邏輯詞條描述 加工比較復雜，它到后來就是一段程序，加工的表達方式有判定表，判定樹如何結構化語言等等，它們要全部寫在一個詞條中是有困難的。953.7.3

49、數(shù)據(jù)字典(DD,Data Dictionary) 2. 定義數(shù)據(jù)的方法 定義絕大多數(shù)復雜事物的方法，都是用被定義的事物的成分的某種組合表示這個事物，這些組成成分又由更低層的成分的組合來定義。從這個意義上說，定義就是自頂向下的分解，所以數(shù)據(jù)字典中的定義就是對數(shù)據(jù)自頂向下的分解。那么，應該把數(shù)據(jù)分解到什么程度呢？一般說來，當分解到不需要進一步定義，每個和工程有關的人也都清楚其含義的元素時，這種分解過程就完成了。 由數(shù)據(jù)元素組成數(shù)據(jù)的方式只有下述三種基本類型： 順序 即以確定次序連接兩個或多個分量； 選擇 即從兩個或多個可能的元素中選取一個； 重復 即把指定的分量重復零次或多次。 可選 即一個分量是

50、可有可無的（重復零次或一次）。963.7.3 數(shù)據(jù)字典(DD,Data Dictionary)符 號含 義解 釋=被定義為+與例如，X=a+b,表示x由a和b組成，或例如，X=a,b, X=a|b,表示x由a或由b組成 | 或重復例如，X=a,表示x由0個或多個a組成mn重復例如，X=3a8,表示x中至少出現(xiàn)3次a，至多出現(xiàn)8次()可選例如，X=(a)表示a可在X中出現(xiàn),也可不出現(xiàn)“”基本數(shù)據(jù)元素例如，X=“a”,表示x為取值為a的數(shù)據(jù)元素連接符例如，X=1.9,表示a可取1到9之中的任一值97例 例：數(shù)據(jù)文件的存折格式的數(shù)據(jù)字典中的定義格式為： 存折=戶名+所號+帳號+開戶日+性質+(密印)

51、+1存取行50 戶名=2字母24 所號=“000”“999” 注：儲蓄所編碼，規(guī)定三位數(shù)字 帳號=“00000001”.“99999999” 注：帳號規(guī)定由八位數(shù)字組成 開戶日=年+月+日 性質=“1”.“6” 注：“1”表示普通用戶，“5”表示工資戶等 印密=”0” 注：“1”表示普通用戶，“5”表示工資戶等 存取行=日期+ (摘要)+支出+存入+余額+操作+復核 日期=年+月+日 年=“00”.“99” 月=“01”.“12” 日=“01”.“31” 摘要=1字母4 注：表明該存取是存？是??？還是換？ 支出=金額 注：金額規(guī)定不超過9999999.99元 金額=“0000000.01”.“

52、9999999.99” 操作=“00001”.“50000”983.7.3 數(shù)據(jù)字典(DD,Data Dictionary) 3. 數(shù)據(jù)字典的用途 數(shù)據(jù)字典最重要的用途是作為分析階段的工具。在數(shù)據(jù)字典中建立的一組嚴密一致的定義有助于改進分析員和用戶之間的通信，因此將消除許多可能的誤解。對數(shù)據(jù)的這一系列嚴密一致的定義也有助于改進在不同的開發(fā)人員或不同的開發(fā)小組之間的通信。如果要求所有開發(fā)人員都根據(jù)公共的數(shù)據(jù)字典描述數(shù)據(jù)和設計模塊，則能避免許多麻煩的接口問題。 數(shù)據(jù)字典中包含的每個數(shù)據(jù)元素的控制信息是很有價值的。因為列出了使用一個給定的數(shù)據(jù)元素的所有程序（或模塊），所以很容易估計改變一個數(shù)據(jù)將產(chǎn)生

53、的影響，并且能對所有受影響的程序或模塊作出相應的改變。 最后，數(shù)據(jù)字典是開發(fā)數(shù)據(jù)庫的第一步，而且是很有價值的一步。993.7.3 數(shù)據(jù)字典(DD,Data Dictionary) 4. 數(shù)據(jù)字典的實現(xiàn) 目前實現(xiàn)數(shù)據(jù)字典有三種常見的途徑：全人工過程，全自動化過程（利用數(shù)據(jù)字典處理程序）和混合過程（用正文編輯程序，報告生成程序等已有的實用程序幫助人工過程）。不論使用哪種途徑實現(xiàn)的數(shù)據(jù)字典都應該具有下述特點： 通過名字能方便地查閱數(shù)據(jù)的定義； 沒有冗余； 盡量不重復在規(guī)格說明的其他組成部分中已經(jīng)出現(xiàn)的信息； 容易更新和修改； 能單獨處理描述每個數(shù)據(jù)元索的信息； 定義的書寫方法簡單方便而且嚴格。 此外

54、，如果再帶有產(chǎn)生交叉參照表、錯誤檢測、一致性校驗等功能則更好。1003.7.3 數(shù)據(jù)字典(DD,Data Dictionary) 如果暫時還沒有自動的數(shù)據(jù)字典處理程序，建議采用卡片形式書寫數(shù)據(jù)字典，每張卡片上保存描述一個數(shù)據(jù)元素的信息。這種做法較好地實現(xiàn)了上述要求，特別是更新和修改起來很方便，能夠單獨處理每個數(shù)據(jù)元素的信息。每張卡片上主要應該包含下述這樣一些信息：名字、別名描述、定義、位置。 當開發(fā)過程進展到能夠知道數(shù)據(jù)元素的控制信息和使用特點時，把這些信息記錄在卡片的背面。101卡片字典的例子名字：訂貨報表別名：訂貨信息描述：每天一次送給采購員的需要訂貨的零件表定義：訂貨報表零件編號+零件名

55、稱+訂貨數(shù)量+目前價格+主要供應者+次要供應者位置：輸出到打印機名字：零件編號別名：描述：唯一地標識庫存清單中一個特定零件的關鍵域定義：零件編號8字符8位置：訂貨報表 訂貨信息 庫存清單名字：訂貨數(shù)量別名：描述：某個零件一次訂貨的數(shù)量定義：訂貨數(shù)量1數(shù)字5位置：訂貨報表 訂貨信息1023.7.4 加工邏輯說明 在數(shù)據(jù)流圖中，每個加工框中只簡單地寫上了一個加工名，這顯然不能表達加工的全部內(nèi)容。隨著自頂向下逐步細化，功能越來越具體，加工邏輯也越來越精細。到最底一層，加工邏輯詳細到可以實現(xiàn)的程度，因此稱為“原子加工”或“基本加工”。如果能夠寫出每一個基本加工的全部詳細邏輯功能，再自底向上綜合，就能完

56、成全部邏輯加工。1033.7.4 加工邏輯說明 在寫基本加工邏輯的說明時，應滿足如下要求： 對數(shù)據(jù)流圖的每一個基本加工，必須有一個加工邏輯說明； 加工邏輯說明必須描述基本加工如何把輸入數(shù)據(jù)流變換為輸出數(shù)據(jù)流的加工規(guī)則； 加工邏輯說明必須描述實現(xiàn)加工的策略而不是實現(xiàn)加工的細節(jié)； 目前用于寫加工邏輯說明的工具有結構化語言、判定表和判定樹。1043.7.4 加工邏輯說明 1. 結構化語言 所謂結構化語言是一種介于自然語言和形式化語言之間的半形式化語言。它是在自然語言基礎上加了一些限制而得到的語言，是使用有限的詞匯和有限的語句來描述加工邏輯。結構化英語的詞匯表由英語命令動詞、數(shù)據(jù)字典中定義的名字、有限的自定義詞和控制結構關鍵詞IF-THEN-ELSE、WHILE-DO、REPEAT-UNTIL、CASE-OF等組成。其動詞的含義要具體，盡可能少用或不用形容詞和副詞。 1053.7.4 加工邏輯說明 下面是商店業(yè)務處理系統(tǒng)中“檢查發(fā)貨單”的例子。 IF the invoice exceeds $500 THEN (發(fā)貨單金額超過$500) IF the account has any invoice more than 60 days ov