1、第一篇 軟件工程學概述第1章 概述 本章的主要目標是介紹軟件工程這門學科，讀完你將了解以下基本內容：軟件工程的相關基本概念：軟件、軟件危機、軟件工程、軟件生命周期、軟件過程等，具體見下述部分介紹。12軟件從業(yè)人員的道德和職業(yè)問題對軟件工程產業(yè)的影響。1軟件工程的相關基本概念：軟件、軟件危機、軟件工程、軟件生命周期、軟件過程等，具體見下述部分介紹。1軟件工程的相關基本概念：軟件、軟件危機、軟件工程、軟件生命周期、軟件過程等，具體見下述部分介紹。1222軟件工程的相關基本概念：軟件、軟件危機、軟件工程、軟件生命周期、軟件過程等，具體見下述部分介紹。12軟件從業(yè)人員的道德和職業(yè)問題對軟件工程產業(yè)的影

2、響。軟件工程的相關基本概念：軟件、軟件危機、軟件工程、軟件生命周期、軟件過程等，具體見下述部分介紹。1 本章的主要目標是介紹軟件工程這門學科，讀完你將了解以下基本內容：當今世界的信息化進程，愈來愈趨向復雜化、人性化和扁平化。軟件工程作為一門工程學科，它的主要目標就是驅使軟件系統(tǒng)向高性價比發(fā)展。 具有實時動態(tài)性 ，抽象、不可觸摸 ，它的面向對象目標不受物理因素限制。軟件工程同時又是一門比較年輕的學科?！败浖こ獭边@一概念是在1968年NATO會議上針對“軟件危機”的議題提出。 1.1 基本概念構建這些軟件系統(tǒng)的早期經驗是：個人英雄主義、作坊式非正規(guī)的軟件開發(fā)并不奏效。投資很大，做得很差。制作既滿

3、足用戶要求、又能按期完成并且不超出項目預算的復雜軟件仍然存在很多困難。軟件工程自1968年以來已得到了長足的發(fā)展。面向對象、構件、WEB服務及云計算等的擴充和提高已成為現(xiàn)實。 1.1.1 軟件1.1.1.1 軟件及組成計算機軟件是與計算機系統(tǒng)操作有關的程序（Program）、規(guī)程、規(guī)則及任何與之有關的文檔和數據。1. 程序 程序是用程序設計語言描述的、適合于計算機處理的語句序列，軟件開發(fā)人員根據需求開發(fā)出來滿足用戶。 目前的程序設計語言有三種類型：機器語言和匯編語言、獨立于機器的面向過程的語言以及獨立于機器的面向問題的語言，后兩種類型為高級語言。 用于科學計算的FORTRAN，用于事務處理的C

4、OBOL，支持結構化程序設計的PASCAL，支持現(xiàn)代軟件開發(fā)的C、ADA，支持面向對象設計方法的C+、JAVA等。 面向問題的語言是第四代語言（4GL），也稱為非過程式語言。數據庫查詢語言（Structure Query Language，SQL）、報表語言、機床控制專用語言和電路設計專用語言等都是面向問題的語言。2. 文檔文檔（Document）是一種數據媒體和其上所記錄的數據。最新的計算機軟件文檔編制規(guī)范是GB/T 8567-2006。1.系統(tǒng)軟件1.1.1.3 軟件的分類1.系統(tǒng)軟件監(jiān)控、分析和控制現(xiàn)實世界發(fā)生的事件，以足夠快的速度對輸入信息并在規(guī)定的時間內做出反應，這類軟件稱為實時軟件

5、。2.實時軟件計算機系統(tǒng)軟件是計算機管理自身資源（如CPU、內存、外存等）、提高計算機的使用效率并為計算機用戶提供各種服務的基礎軟件。1.系統(tǒng)軟件此類軟件以數值算法為基礎，對數值量進行處理和計算。4.科學與工程計算軟件用于處理事務信息，特別是商務信息的計算機軟件。5.事務處理軟件嵌入式計算機系統(tǒng)將計算機嵌入在某一系統(tǒng)中，使之成為該系統(tǒng)的重要組成部分，控制該系統(tǒng)的運行，進而實現(xiàn)一個特定的物理過程。3.嵌入式軟件此類軟件以數值算法為基礎，對數值量進行處理和計算。4.科學與工程計算軟件嵌入式計算機系統(tǒng)將計算機嵌入在某一系統(tǒng)中，使之成為該系統(tǒng)的重要組成部分，控制該系統(tǒng)的運行，進而實現(xiàn)一個特定的物理過程

6、。3.嵌入式軟件嵌入式計算機系統(tǒng)將計算機嵌入在某一系統(tǒng)中，使之成為該系統(tǒng)的重要組成部分，控制該系統(tǒng)的運行，進而實現(xiàn)一個特定的物理過程。3.嵌入式軟件嵌入式計算機系統(tǒng)將計算機嵌入在某一系統(tǒng)中，使之成為該系統(tǒng)的重要組成部分，控制該系統(tǒng)的運行，進而實現(xiàn)一個特定的物理過程。3.嵌入式軟件4.科學與工程計算軟件此類軟件以數值算法為基礎，對數值量進行處理和計算。4.科學與工程計算軟件個人計算機上使用的軟件包括系統(tǒng)軟件和應用軟件兩類。7.個人計算機軟件計算機輔助軟件工程（Computer-Aided Software Engineering，CASE）是指軟件開發(fā)和管理人員在軟件工具的幫助下進行軟件產品的開

7、發(fā)、維護以及開發(fā)過程的管理。8.CASE工具軟件支持計算機系統(tǒng)產生人類某些智能的軟件。人工智能軟件常用的計算機語言有LISP和PROLOG等。6.人工智能軟件個人計算機上使用的軟件包括系統(tǒng)軟件和應用軟件兩類。7.個人計算機軟件個人計算機上使用的軟件包括系統(tǒng)軟件和應用軟件兩類。7.個人計算機軟件1.1.1.4 軟件的發(fā)展階段第一階段 （20世紀50年代初至20世紀60年代初）是計算機系統(tǒng)開發(fā)的初期階段。這時的通用計算機由于價格昂貴、體積大、功耗高、機器不穩(wěn)定和需要專人維護等原因，只能放在公共的實驗室內供大家使用。第二階段 （20世紀60年代中期至20世紀70年代末）引進了多用戶、多道程序和人機交

8、互等新概念。實時系統(tǒng)可以從多路信號源上采集、處理、分析和轉換數據，在相當短的時間輸出計算結果。 第三階段 （20世紀70年代中期至20世紀80年代末）分布式系統(tǒng)、計算機網絡、嵌入式計算機系統(tǒng)有了很大發(fā)展。微處理器、個人計算機、高性能的桌面工作站具有相當高的性價比，廣泛走進了人們工作、生活的各個方面。第四階段 （自20世紀80年代末期開始至現(xiàn)在）在很多應用領域，人們開始采用面向對象的技術，專家系統(tǒng)、人工智能軟件、構件開發(fā)、服務化軟件、云計算等開始走向實際應用。 20世紀90年代末，Internet技術。 21世紀，電子商務、電子政務，服務化軟件、云計算新型軟件模式的出現(xiàn)。1.1.2 軟件危機1.

9、1.2.1 軟件危機的表現(xiàn) 20世紀60年代末至20世紀70年代初，“軟件危機”直到1968年在原西德加米施（Garmish）召開的國際軟件工程會議上才被世人所注目。 計算機生物圈的計算機硬件，卻有一個可怕的摩爾定律。 人月神話(The Mythical Man-Month)。 沒有銀彈（No Silver Bullet）。 軟件危機概括地包含下述兩方面的問題：如何開發(fā)軟件、如何維護數量不斷膨脹的已有軟件。 軟件危機主要有以下一些典型表現(xiàn)：對軟件開發(fā)成本和進度的估計常常很不準確。 用戶對“已完成”的系統(tǒng)不滿意很普遍。 軟件產品的質量往往靠不住。 軟件常常不可維護。 缺失適當的文檔資料。 軟件成

10、本在計算機系統(tǒng)總成本中的比例逐年上升。軟件開發(fā)生產率的速度，遠遠跟不上計算機的普及 和深入趨勢。 1.1.2.2 軟件危機的表現(xiàn)用戶對軟件需求的描述不精確，存在遺留、二義性、錯誤的情況經常發(fā)生 。 軟件開發(fā)人員對用戶需求的理解與用戶的本來愿望有差異 。 大型軟件項目需要組織一定的人力共同參與完成 。 軟件項目開發(fā)人員不能有效、獨立自主地處理大型軟件的全部關系和各個分支 。 缺乏有力的方法學和工具的支持 。 軟件產品的特殊性和人類智力的局限性導致人們無力處理很多復雜問題 。1.1.2.3 軟件危機的克服途徑 用現(xiàn)代工程的概念、原理、技術和方法進行軟件的開發(fā)、管理、維護和更新。計算機科學技術誕生了

11、一個新的研究領域軟件工程1.1.3 軟件工程 1968年，北大西洋公約組織（NATO）召開計算機科學會議，弗里茲.鮑爾（Fritz Bauer）首次提出了“軟件工程”的概念 。1.1.3.1 軟件工程的定義 1993年，IEEE對軟件工程的定義為：“將系統(tǒng)的、規(guī)范的、可度量的工程化方法應用于軟件開發(fā)、運行和維護的全過程及有關上述方法的研究”。軟件工程包括三個基本要素：方法、工具和過程 。1.1.3.2 軟件工程的基本原理 著名的軟件工程專家B. W. Boehm綜合這些學者們的意見并總結了TRW公司多年開發(fā)軟件的經驗，1983年在一篇論文中提出了軟件工程的7條基本原理。1. 用分階段的生命周期

12、計劃嚴格管理2. 階段評審 3. 嚴格的產品控制 盡可能重用。 限定每一層的副作用，減少耦合度。 盡可能重用。4. 現(xiàn)代的程序設計技術7. 軟件工程實踐需不斷改進6. 開發(fā)人員應少而精5. 結果應能清楚地審查1.1.3.3 軟件工程的目標可修改性（Modifiability）有效性（Efficiency）可靠性（Reliability） 可理解性（Understandability）可維護性（Maintainability）可重用性（Reusability） 可適應性（Adaptability） 可移植性（Portability） 可追蹤性（Traceability） 可互操作性（Intero

13、perability）1.1.3.4 軟件工程的原則抽象（Abstraction） 信息隱藏（Information Hiding） 模塊化（Modularity） 局部化（Localization）一致性（Consistency） 完整性（Completeness） 可驗證性（Verifiability）1.1.4 軟件生命周期軟件產品從形成概念開始，經過開發(fā)、使用和維護，直到最后退役的全過程稱為軟件生存周期（Software Life Cycle）。軟件生命周期由軟件定義、軟件開發(fā)和軟件使用維護退役3個時期 。1. 問題定義 要解決的問題是什么？2. 可行性研究 問題定義所確定的問題有行得

14、通的解決 方法嗎？此問 題值不值得去解決？4. 總體設計 概括地說，應該怎樣實現(xiàn)目標系統(tǒng)？3. 需求分析 為了解決這個問題，目標系統(tǒng)必須要做什么？5. 詳細設計 以比較抽象的方式提出解決問題的方法。 6. 編碼和單元測試 寫出容易理解和容易維護的正確程序模塊。 7. 綜合測試 通過各種類型的測試使軟件達到預定的要求。 9. 軟件的維護 維護是對軟件產品進行修改或對需求變化做出響應的過程。8. 軟件的使用 軟件的使用是軟件發(fā)揮社會和經濟效益的重要 實施階段。 10. 軟件的退役 終止對軟件產品的支持，軟件停止使用。 1.1.5.1 瀑布模型瀑布模型（Waterfall Model）也稱之為軟件生

15、存周期模型，由W.Royce于1970年提出。此模型根據軟件生存周期各個階段的任務，逐步進行階段性變換，直至得到用戶確認的產品為止。 以充分有效的軟件需求有效為前提，具有順序性、依賴性、推遲時間以及質量保證的特點。它也不是“萬能藥”，主要體現(xiàn)在： 在軟件開發(fā)初始階段指明軟件系統(tǒng)的全部需求是不太可 能的，有時甚至是不現(xiàn)實的。 需求確定后，用戶和軟件項目負責人要等相當長的時間 （經過設計、實現(xiàn)、測試、運行）才能得到一份軟件的 最初版本。 “瀑布模型是借助文檔驅動的”是它的另一個主要缺點。 快速開發(fā)原型的本質是“快速”，實現(xiàn)的途徑有三種：利用個人計算機模擬軟件系統(tǒng)的人機界面和人機交互方式。開發(fā)一個工

16、作原型，實現(xiàn)軟件系統(tǒng)的部分功能，而這部分 功能是重要的，也可能是容易產生誤解的。找來一個或幾個正在運行的類似軟件，利用這些軟件向客 戶展示軟件需求中的部分或全部功能。1.1.5.2 原型模型建造原型的過程如圖1.5所示。 原型不能稱之為軟件，UNIX Shell和超文本都是廣泛的快速原型語言，近年來，廣泛地使用第四代語言（4GL）構建快速原型。 1.1.5.3 增量模型 增量模型（Incremental Model）也稱為漸進模型，它把軟件產品作為一系列的增量構件來設計、編碼、集成和測試。增量模型的優(yōu)點體現(xiàn)在：增量模型分批逐步地向用戶提交產品，整個軟件產品被分解成許多增量構件，開發(fā)人員一個構件

17、接一個構件地向用戶提交產品。增量模型逐步增加產品功能，可以使用戶有較充裕的時間學習和適應新產品功能性能，從而減少一個全新的軟件可能給客戶帶來的不適應。增量模型的實施也存在一些難度：在把每個新的增量構件集成到現(xiàn)有軟件體系結構時，必須不破壞原來已開發(fā)出的產品。 在設計軟件體系結構時，必須使之利于擴充，向現(xiàn)有產品中加入新構件的過程也要簡單、方便，即體系結構必須是開放的。圖1.6描繪了一種高風險的增量模型。1.1.5.4 螺旋模型螺旋模型（Spiral Model）是TRW（湯普森-拉美-伍爾德里奇公司，簡稱為TRW）的B. Boehm于1988年提出的。它基于軟件生存周期模型與原型模型的結合 。螺旋

18、模型主要由四部分組成：需求定義、風險分析、工程實現(xiàn)和評審。 螺旋模型在支持大型軟件開發(fā)方面具有廣泛的應用前景，適用于面向規(guī)格說明、面向過程和面向對象的軟件開發(fā)模型。 1.1.5.5 噴泉模型噴泉模型（Fountain Model）是一種典型的面向對象軟件開發(fā)模型，迭代是它的主旨思想。 “噴泉”這個詞體現(xiàn)了面向對象軟件開發(fā)過程迭代和無縫的特性，如圖1.8。 1.1.5.6 基于四代技術的模型第四代語言（4GL）是R. Ross于1981年提出，采用四代技術開發(fā)軟件的模型，如圖1.9 1.1.5.7 變換模型 變換模型（Transformational Model）是基于形式化規(guī)格說明語言及程序變

19、換的軟件開發(fā)模型。 軟件需求分析確定后，用某種形式化的需求規(guī)格說明語言（如VDM的META-IV、CSP和Z）描述，生成形式化的規(guī)格說明。 形式化規(guī)格說明語言及其變換描述的研究方興未艾，人們采用的技術手段主要有：基于模型的規(guī)格說明及其變換技術；基于代數結構的規(guī)格說明及其變換技術；基于時序邏輯的規(guī)格說明及驗證技術；基于可視形式化技術的規(guī)格說明等等。1.1.5.8 組合模型組合的方式有兩種： 第一種方式是以一種模型為主，嵌入另外一種或幾種模型。 第二種方式是建立軟件開發(fā)的組合模型。 1269111314的路徑規(guī)劃軟件開發(fā)，就是生存周期模型 帶有原型的生存周期模型，開發(fā)路徑

20、1327111314是原型模型 1581291314是螺旋模型 14111314是基于四代技術的模型 1.1.6 軟件工程面臨的挑戰(zhàn)軟件工程在21世紀面臨以下三大挑戰(zhàn)：遺留系統(tǒng)的挑戰(zhàn)多樣性的挑戰(zhàn)交付上的挑戰(zhàn)1.2 軟件工程從業(yè)人員的職業(yè)和道德素養(yǎng)軟件工程人員必須堅持誠實正直的行為準則包括：機密；工作能力；知識產權；計算機濫用； 在這一方面，職業(yè)協(xié)會和機構肩負重任。ACM（美國計算機協(xié)會）、IEEE（電氣和電子工程師協(xié)會）和英國計算機協(xié)會等組織頒布了職業(yè)行為準則或職業(yè)道德準則，凡是加入這些組織的成員必須嚴格遵守。 軟件工程人應當遵守以下八條原則：公眾感 ；客戶和雇主 ；產品 ；判斷力 ；管理 ；

21、職業(yè)感 ；同事 ；自己 ； 在我們的職業(yè)生涯中，每個人都會面臨這些困惑，幸運的是，在多數情況下，這些困惑要么不嚴重，要么不難解決。 當雇主的行為不合乎道德時，職業(yè)工程人員的處境尤為艱難。安全不是絕對的。 另一個道德問題是軍事項目和核項目的參與。雇主和所有雇員事先相互溝通各自的觀點非常重要。 軟件工程從業(yè)人員的道德問題研究最好要聯(lián)系軟件工程的實際，而不是將其作為一個孤立的問題來研究，且不能僅僅歸為一個單純的哲學問題來看待。習題1 假設自己是一家軟件公司的總工程師，當把圖1.1給手下的軟件工程師觀看，告訴他們及早發(fā)現(xiàn)并改正錯誤的重要性時，有人不同意這個觀點，認為要求在錯誤進入軟件之前就清除它們是不

22、現(xiàn)實的，并向你舉例：如果一個故障是編碼錯誤造成的，那么一個人怎么能在設計階段清除它呢？應該怎么駁斥他？ 職業(yè)工程人員是否應該像醫(yī)生或律師一樣要頒發(fā)資格證書？分組討論一下。THANKS第1篇 軟件工程學概述第2章 計算機系統(tǒng)工程基于計算機系統(tǒng)工程的各類相關因素。1系統(tǒng)模型與建模、系統(tǒng)規(guī)格說明及評審。2本章的主要目標是介紹計算機系統(tǒng)工程的概念、解釋系統(tǒng)工程的因素特征與軟件工程及軟件工程師的關系。讀完本章，你將了解以下基本內容： 大多數軟件項目都是為了滿足某種需求的軟件產品而建立起的一個系統(tǒng)化工程過程，這些軟件必須在計算機系統(tǒng)的支持下才能工作。 計算機系統(tǒng)工程是指構造基于計算機系統(tǒng)有關的過程、方法和

23、技術，這是一種問題求解的活動序列。 大多數軟件項目都是為了滿足某種需求的軟件產品而建立起的一個系統(tǒng)化工程過程，這些軟件必須在計算機系統(tǒng)的支持下才能工作。 2.1 系統(tǒng)與系統(tǒng)工程1. 功能特性2. 非功能特性 系統(tǒng)的復雜性很大程度體現(xiàn)在可靠性上，系統(tǒng)總體的可靠性涉及到三方面： 硬件可靠性； 軟件可靠性； 系統(tǒng)操作員可靠性。2.1.1 系統(tǒng)總體特性2.1.1 系統(tǒng)總體特性 系統(tǒng)工程師根據系統(tǒng)需求為硬件系統(tǒng)指派任務，產生硬件需求。硬件工程式分為3個階段 ：第一階段：制定開發(fā)計劃，經評審確定項目成本預算和工程進度；展開詳細需求分析，經評審確定硬件規(guī)格說明。第二階段：設計分析，以圖的形式展現(xiàn)設計結果；必

24、要時建造原型，并不斷完善測試原型； 制造分析，畫出硬件生產圖。第三階段：按照質量保證計劃和要求生產硬件產品。2.1.3 軟件和軟件工程 軟件與硬件、軟件工程與硬件工程分別是基于計算機系統(tǒng)和基于計算機的系統(tǒng)工程的重要組成部分。 目前，大多數基于計算機系統(tǒng)的軟部件，都是軟件工程師自行開發(fā)的。軟部件由源程序、數據和文檔三部分組成。 系統(tǒng)軟件和應用軟件的接口由系統(tǒng)軟件決定。無論基于計算機的系統(tǒng)功能和性能如何，它們的結構都可以用IPO（Input Process Output）模型表示。 借助軟件工程的過程、方法和工具，軟件工程師開發(fā)基于計算機的系統(tǒng)。無論是哪種軟件工程過程模型，它們都是涵蓋軟件項目的定

25、義、開發(fā)、驗證、提交和維護階段 。軟件定義階段的任務： 制定項目規(guī)劃 ； 需求分析與定義 ； 確定軟件性能和資源約束； 定義軟件要素驗收標準 ； 軟件開發(fā)階段的任務是完成軟件總體結構及數據設計、過程設計和編碼三部分；軟件工程過程的最后階段是軟件驗證、提交和維護。驗證的任務 ： 制定軟件測試計劃和過程，產生測試文檔和 測試題目 ； 對軟件的每個模塊進行單元測試、驗證模塊 的功能是否符合設計要求； 對整個軟件進行綜合測試； 組織專家和用戶對測試結果進行評審 ；總體結構設計和數據設計的任務 ： 設計模塊結構； 定義界面并建立數據結構 ；軟件過程設計的任務 ： 詳細描述軟件規(guī)格說明中的每一個模塊； 對

26、模塊進行評審。通過評審模塊的詳細描述將構 成詳細設計規(guī)格說明 ；軟件編碼的任務 ： 用恰當的編程語言對詳細描述模塊進行編碼，生 成 程序 ；評審通過后，進行軟件提交，主要任務包括 ：對已生成的記錄和內部文檔進行整理、分類和存檔；開發(fā)用戶手冊、建立適當的配置控制機制 ；將軟件提交給用戶，必要時還應負責把軟件安裝到用戶環(huán)境中 ；2.1.4 人機交互工程 現(xiàn)在，“友好的人機交互”已成為計算機系統(tǒng)的一項重要技術衡量指標，人機工程也已成為基于計算機系統(tǒng)開發(fā)的一項重要內容。人機工程一般包括以下幾個步驟： 活動分析 ； 動作定義與設計 ； 人機交互的對話設計 ； 用戶環(huán)境設計 ； 設計原型 ；2.1.5 數

27、據庫工程一個基于計算機的系統(tǒng)工程，至少包括三個部分：硬件工程、軟件工程和人機交互過程。 開發(fā)一個數據庫系統(tǒng)是一項復雜而龐大的軟件工程項目，一般情況下稱之為數據庫工程，它主要完成以下任務： 調查用戶的信息需求和對信息處理的要求；進行可行性論證；提出成本預算和工作計劃等 ； 論證、選擇和購置支持數據庫系統(tǒng)的硬件和軟件 ； 設計與實現(xiàn) ； 數據庫中的數據是按照系統(tǒng)確定的范圍和用戶的需求收集、整理、儲存 ； 數據庫管理人員（比如DBA）是數據庫工程的重要組成部分 ；2.2 系統(tǒng)模型與建?；顒?輸入-處理-輸出（IPO）結構是系統(tǒng)建模的基礎，它將基于計算機的系統(tǒng)換算成一個信息變換模型。同時，Hatley

28、和Pirbhai補充了用戶界面、維護及自測試方面的處理內容。 2.2.1 系統(tǒng)模型1. 結構圖 系統(tǒng)工程師用結構模板開發(fā)系統(tǒng)模型。 圖2.5是某某傳送線在線貨物分類系統(tǒng)的總體關系圖。 系統(tǒng)工程師借助ACD可以定義各子系統(tǒng)的結構流圖（AFD）。 2. 系統(tǒng)結構規(guī)格說明 結構圖規(guī)格說明（ADS）描述了子系統(tǒng)信息以及子系統(tǒng)之間的控制流和信息流。每個子系統(tǒng)的結構圖規(guī)格說明都應包括系統(tǒng)模板說明書、系統(tǒng)結構數據字典和系統(tǒng)結構互連圖。 2.2.2 系統(tǒng)建模及模擬 為了減少在真實環(huán)境中試驗的風險和代價，在系統(tǒng)分析和設計階段普遍采用系統(tǒng)建模和模擬技術。 從時間維角度，可以把系統(tǒng)模型定位為靜態(tài)模型和動態(tài)模型，靜態(tài)

29、模型不關乎時間參數，動態(tài)模型則不同。從計算機系統(tǒng)參數的隨機性來看，模型有確定和隨機之分。 系統(tǒng)模擬是用一個系統(tǒng)表示某個實際系統(tǒng)或抽象系統(tǒng)中選定行為的特征 。主要步驟是： 分析問題、確定模擬的目標 ； 建立模型 ； 運行模型并分析模擬結果 ； 若需要，修改模型 ； 撰寫模擬文檔 ；2.3 系統(tǒng)規(guī)格與評審說明表2.1系統(tǒng)規(guī)格說明目錄2.3.1 系統(tǒng)規(guī)格I. 引言A. 文檔的范圍和目的B. 概述 1. 目標 2. 約束II. 功能和數據描述A. 系統(tǒng)結構 1. 結構關系圖 2. 結構關系圖描述III. 子系統(tǒng)描述A. 子系統(tǒng)N的結構圖規(guī)格說明 1. 結構流圖 2. 系統(tǒng)模型說明3. 性能問題 4.

30、設計約束條件 5. 分配系統(tǒng)部件B. 結構字典C. 結構連結圖和說明IV. 系統(tǒng)建模和模擬結果A. 用于模擬的系統(tǒng)模型B. 模擬結果C. 特殊性能V. 項目問題A. 開發(fā)成本B. 進度VI. 附錄2.3.2 評審說明 系統(tǒng)規(guī)格說明評審過程分管理評審和技術評審兩個階段。管理評審需回答： 系統(tǒng)是否有一個穩(wěn)定的商業(yè)需求，系統(tǒng)開發(fā)是否有意義？ 系統(tǒng)開發(fā)是否有市場價值或社會效益？ 系統(tǒng)開發(fā)是否還有其他選擇方案？ 系統(tǒng)各個部分的開發(fā)風險怎樣？ 系統(tǒng)開發(fā)所需資源是否已具備？ 成本和進度計劃是否恰當？等等。技術評審需回答： 系統(tǒng)功能復雜性是否與開發(fā)風險、成本和進度評估保持一致？ 系統(tǒng)采用的術語、系統(tǒng)與子系統(tǒng)功

31、能定義是否足夠詳細？系統(tǒng)與環(huán)境的接口以及各子系統(tǒng)間的接口定義是否詳細？系統(tǒng)各個部分的開發(fā)風險怎樣？系統(tǒng)規(guī)格說明是否指明系統(tǒng)性能、可靠性和可維護性方面的問題？系統(tǒng)規(guī)格說明是否為后續(xù)的硬件工程、軟件工程打下堅實的基礎？ 系統(tǒng)規(guī)格說明評審完成后，系統(tǒng)開發(fā)可以按照硬件工程、軟件工程、數據庫工程、人機交互等并行展開。從第三章起，主要任務介紹軟件工程。習題2 討論并描述系統(tǒng)分析員應該具備的主要知識結構和基本素質。軟件開發(fā)人員和用戶分別擔任系統(tǒng)分析員有哪些優(yōu)勢和缺陷。 找出并改正程序邏輯中的錯誤。 THANKS第2篇 軟件定義第3章 可行性研究本章的主要目標是介紹軟件可行性研究階段的相關工作。讀完本章，你將

32、了解以下基本內容：1軟件可行性論證需考慮的幾個因素、任務和執(zhí)行過程。1軟件可行性論證需考慮的幾個因素、任務和執(zhí)行過程。1軟件可行性論證需考慮的幾個因素、任務和執(zhí)行過程。13可行性研究報告中成本/效益分析、技術分析和可行性方案的分配與權衡。可行性研究中相關的系統(tǒng)流程元素及模型表達。2軟件可行性論證需考慮的幾個因素、任務和執(zhí)行過程。1軟件可行性論證需考慮的幾個因素、任務和執(zhí)行過程。12可行性研究中相關的系統(tǒng)流程元素及模型表達。2 只要資源和時間不加以限制，所有的項目都是可行的。 軟件可行性研究的目的，就是用最小的代價在盡可能短的時間內確定問題是否能夠解決?？尚行匝芯康闹髦疾皇墙鉀Q問題，而是確定問題

33、是否值得去解首先需要進一步分析和澄清問題定義其次，在澄清了問題定義后，分析人員應該導出系統(tǒng)的邏輯模型。3.1 可行性研究的任務可行性，一般來講，主要集中在以下幾個方面： 技術可行性。 經濟可行性。 操作可行性。 法律可行性。 抉擇?？尚行匝芯啃枰臅r間長短取決于工程的規(guī)模， 通常情況下，可行性研究的成本只是預期工程總成本的5%10%。3.2 可行性研究過程典型的可行性研究過程需要下述一些步驟：復查系統(tǒng)規(guī)模和目標研究目前正在使用的系統(tǒng)導出新系統(tǒng)的高層邏輯模型再次定義問題導出和評價供選擇的解法推薦行動方針草擬開發(fā)計劃書寫文檔并提交審查3.3 系統(tǒng)流程元素及模型表達 需要在可行性研究階段大體設計未來

34、物理系統(tǒng)的概貌，這里需要系統(tǒng)流程圖。 系統(tǒng)流程圖是概括描繪物理系統(tǒng)的傳統(tǒng)工具。基本思想是用圖形符號以黑盒子形式描繪組成系統(tǒng)的每個部件（程序、文檔、數據庫、人工過程等）。3.3.1 元素符號表3.1 基本符號 符號名 稱說 明處理能改變數據值或數據位置的加工或部件，例如程序、處理機、人工加工等均為處理輸入/輸出表示輸入或輸出，是一個廣義的不指明具體設備的符號連接指出轉到圖的另一部分或從圖的另一部分轉來，通常在同一頁上換頁連接指出轉到另一頁圖上或由另一頁圖轉來數據流用來連接其他符號，指明數據流動方向表3.2 系統(tǒng)符號名 稱說 明穿孔卡片表示用穿孔卡片輸入或輸出，也可表示一個穿孔卡片文件文檔通常表示

35、打印輸出，也可表示用打印終端輸入數據磁帶磁帶輸入輸出，或表示一個磁帶文件聯(lián)機存儲表示任何種類的聯(lián)機存儲，包括磁盤、磁鼓、軟盤和海量存儲器件等磁盤磁盤輸入輸出，也可表示存儲在磁盤上的文件或數據庫磁鼓磁鼓輸入輸出，也可表示存儲在磁鼓上的文件或數據庫顯示CRT終端或類似的顯示部件，可用于輸入或輸出，也可既輸入又輸出人工輸入人工輸入數據的脫機處理，例如，填寫表格人工操作人工完成的處理，例如，會計在工資支票上簽字輔助操作使用設備進行的脫機操作通信鏈路通過遠程通信線路或鏈路傳送數據3.3.2 舉例 該裝配廠使用一臺小型計算機處理更新庫存清單主文件和產生定貨報告的任務。零件庫存量的每一次變化稱為一個事務，由

36、放在倉庫中的CRT終端輸入到計算機中；系統(tǒng)中的庫存清單程序對事務進行處理，更新存儲在磁盤上的庫存清單主文件，并且把必要的定貨信息寫在磁盤上。最后，每天由報告生成程序讀一次磁盤，且打印出定貨報告。 某裝配廠有一存放零件的倉庫，倉庫中現(xiàn)有的各種零件的數量以及每種零件的庫存量臨界值等數據記錄在庫存清單主文件中。當倉庫中零件數量有變化時，應及時修改庫存清單主文件，如果哪種零件的庫存量少于它的庫存量臨界值，則應報告給采購部門以便定貨，規(guī)定每天向采購部門送一次定貨報告。 該裝配廠使用一臺小型計算機處理更新庫存清單主文件和產生定貨報告的任務。零件庫存量的每一次變化稱為一個事務，由放在倉庫中的CRT終端輸入到

37、計算機中；系統(tǒng)中的庫存清單程序對事務進行處理，更新存儲在磁盤上的庫存清單主文件，并且把必要的定貨信息寫在磁盤上。最后，每天由報告生成程序讀一次磁盤，且打印出定貨報告。 某裝配廠有一存放零件的倉庫，倉庫中現(xiàn)有的各種零件的數量以及每種零件的庫存量臨界值等數據記錄在庫存清單主文件中。當倉庫中零件數量有變化時，應及時修改庫存清單主文件，如果哪種零件的庫存量少于它的庫存量臨界值，則應報告給采購部門以便定貨，規(guī)定每天向采購部門送一次定貨報告。3.4 成本/效益分析 開發(fā)一個軟件也是投資，期望將來獲得更大的經濟效益。經濟效益通常表現(xiàn)為減少運行費用或（和）增加收入。3.4.1 成本估計代碼行技術任務分解技術自

38、動估計成本技術表3.3 典型環(huán)境下各個開發(fā)階段需要使用的人力的百分比任務人力（%）可行性研究5需求分析10總體設計和詳細設計25編碼和單元測試20綜合測試40總計1003.4.2 成本/效益分析方法成本/效益分析的第一步是估計開發(fā)成本、運行費用和新系統(tǒng)將帶來的經濟效益。為了保險起見，以后在進行成本/效益分析時一般假設生命周期為5年。通常用利率的形式表示貨幣的時間價值。 通常用投資回收期衡量一項開發(fā)工程的價值。所謂投資回收期就是使累計的經濟效益等于最初投資所需要的時間。 衡量工程價值的另一項經濟指標是工程的純收入，也就是在整個生命周期之內系統(tǒng)的累計經濟效益（折合成現(xiàn)在值）與投資之差。這相當于比較

39、投資開發(fā)一個軟件系統(tǒng)和把錢存在銀行（或貸給其他企業(yè)）這兩種方案的優(yōu)劣。4.投資回收率3.純收入 設想把數量等于投資額的資金存入銀行，每年年底從銀行取回的錢等于系統(tǒng)每年預期可以獲得的效益。1.貨幣的時間價值2.投資回收期3.5 技術分析用于技術分析的方法，有數學模型和優(yōu)化技術、概率和統(tǒng)計、排隊論、控制論等。圖3.2說明在模型化的過程中信息的整個流程： BlanChard和Fabrychy為系統(tǒng)的技術分析定義了一套使用模型的準則。模型應表現(xiàn)出待評估系統(tǒng)構成的動態(tài)特性，其操作應當盡量接近真實的結果；模型應包括所有的相關元素，并且保證其可靠性；模型應突出表現(xiàn)與現(xiàn)實問題最相關的因素，對次要的因素，要謹慎

40、地回避它們；模型設計應盡量簡單，并應很快解決問題。模型設計應制定要求，以便修改或者擴充，并在需要時進行評估。3.6 方案的分配與權衡一旦解決了與分析任務相關的問題，就應開始考慮候選的解決方案對候選系統(tǒng)配置方案的整個評估過程如圖3.3和圖3.4所示習題31.問題描述：為方便儲戶，某銀行擬開發(fā)計算機儲蓄系統(tǒng)。儲戶填寫的存款單或取款單由業(yè)務員輸入系統(tǒng)，如果是存款，系統(tǒng)記錄存款人姓名、住址、存款類型、存款日期、利率等信息，并印出存款單給儲戶；如果是取款，系統(tǒng)計算利息并印出利息清單給儲戶。對這段問題描述進行分析，畫出相關的系統(tǒng)業(yè)務流程。2.問題描述：為方便旅客，某航空公司擬開發(fā)一個機票預訂系統(tǒng)。旅行社把

41、預訂機票的旅客信息（姓名、性別、工作單位、身份證號碼、旅行時間、旅行目的地等）輸入系統(tǒng)，系統(tǒng)為旅客安排航班，印出取票通知和賬單，旅客在飛機起飛的前一天憑取票通知和賬單交款取票，系統(tǒng)校對無誤即印出機票給旅客。對這段問題描述進行分析，畫出相關的系統(tǒng)業(yè)務流程。3.問題描述：住院病人主要由護士護理，這樣做不僅需要大量護士，而且由于不能隨時觀察危重病人的病情變化，可能會延誤救治時機。某醫(yī)院打算開發(fā)一個以計算機為中心的患者監(jiān)護系統(tǒng)，醫(yī)院對患者監(jiān)護系統(tǒng)的基本要求是隨時接收每個病人的生理信號（脈搏、體溫、血壓、心電圖等），定時記錄病人情況以形成患者日志，當某個病人的生理信號超出醫(yī)生規(guī)定的安全范圍時向值班護士發(fā)

42、出警告信息，此外，護士在需要時還可以要求系統(tǒng)印出某個指定病人的病情報告。對這段問題描述進行分析，畫出相關的系統(tǒng)業(yè)務流程。THANKS第2篇 軟件定義第4章 結構化需求分析本章的主要目標是介紹軟件需求分析的相關工作。讀完本章，你將了解以下基本內容：需求分析的基礎。1結構化面向數據流的需求分析。2結構化需求分析常用工具。34.1 需求分析基礎 軟件需求是指用戶對目標軟件系統(tǒng)在功能、行為、性能、設計約束等方面的期望。最終形成需求規(guī)格說明。 需求分析階段是介于系統(tǒng)分析和軟件設計階段間的重要橋梁。需求分析可分為問題分析、需求描述及需求評審3個階段。4.1.1 需求分析的任務與原則 在問題分析階段，分析人

43、員通過對問題及其環(huán)境的理解、分析和綜合，清除用戶需求的模糊性、歧義性和不一致性，并在用戶的幫助下對相互沖突的要求進行折衷。 需求描述階段的主要任務是以需求模型為基礎，考慮到問題的軟件可解性，生成需求規(guī)格說明和初步的用戶手冊。 在需求評審階段，分析人員需在用戶和軟件設計人員的配合下對自己生成的需求規(guī)格說明和初步的用戶手冊進行復核，以確保軟件需求的全面性、精確性和一致性，并使用戶和設計人員對需求規(guī)格說明及用戶手冊的理解達成一致。4.1.2 需求初步獲取技術訪談與會議4.1.2.1需求實例4.1.2.4深入用戶工作環(huán)境4.1.2.2用戶與開發(fā)人員一同參與4.1.2.34.1.2.4 需求實例問題描述

44、：家庭保安市場正以每年40%的速度增長?，F(xiàn)希望建立一種基于微處理器的家庭保安系統(tǒng)，它能夠識別異常事件并采取相應的防護措施。這些異常事件應包括非法進入、火災、水淹等等。一旦異常情形被相應的傳感器探測出來，系統(tǒng)應自動通過電話向監(jiān)控中心報警。此外，系統(tǒng)還應該允許戶主對其行為實施程序式控制。針對此問題，軟件研發(fā)聯(lián)合小組首先制定工作制度：每次會議開始前必須有確定的議程，參加者需要針對各項議程進行充分的準備，這種準備不僅是思想上的，還應成形于文字。 最后，初步分析活動應形成結論性文檔，該文檔將作為后續(xù)分析活動的基礎。經過初步分析后，“家庭保安系統(tǒng)”的部分需求文檔（不包括約束條件和測試標準）如下： “家庭保

45、安系統(tǒng)”的軟件允許用戶在安裝時進行系統(tǒng)配置，實施對傳感器的監(jiān)控并通過控制面板與用戶進行信息交互。配置操作包括：(1)指定每一傳感器的種類和編號；(2)設置開、關機密碼；(3)指定報警電話號碼；(4)指定報警延遲和電話重撥延遲時間（以秒為單位）。 當軟件系統(tǒng)接收到傳感器發(fā)出的數據后，判斷是否出現(xiàn)異常事件。若是，則在指定的延遲時間內撥報警電話，撥號操作將按照重撥延遲反復進行，直至電話接通。然后軟件系統(tǒng)負責報告時間、地點和異常事件的性質。 開機后，軟件系統(tǒng)負責顯示當前工作狀態(tài)，接收并處理用戶指令。4.1.3 需求建模軟件目標系統(tǒng)可通過模型刻畫所涉及的信息、處理功能及實際運行時的外部行為。建立軟件模型

46、是分析活動的焦點。4.1.4 問題抽象、問題分解與多視點分析抽象方法要求分析人員在分析過程中善于捕捉用戶描述或問題本身所固有的一般特殊關系，首先關注一般問題的解決途徑，進而指導特殊問題的求解。問題分解也是普遍適用于分析各階段的一般性方法。與問題分解相對應，還有一種“視角分解”方法廣泛應用于需求分析活動， 這就是所謂的“多視點分析”。4.1.5 支持需求分析的快速原型技術 一旦確定采用快速原型技術后，分析人員不妨遵循以下步驟： 利用各種分析技術和方法，生成一個簡化的需求規(guī)格說明； 對前述需求規(guī)格說明進行檢查、修訂后，生成設計規(guī)格說明。一般情況，為了快速生成原型，軟件的設計只關心軟件的總體結構、用

47、戶界面和數據設計，不注重過程內部的控制流程設計。 在現(xiàn)有工具或環(huán)境的幫助下快速生成可運行的軟件原型并進行測試、完善和改進?？捎玫闹饕ぞ哂锌芍赜玫能洸考?、用戶界面 自動生成器等快速原型支持工具； 將原型提交給用戶評估并征詢改進意見； 上述過程將反復迭代進行，直到用戶完全認可為止。4.1.6 需求規(guī)格說明與評審它必須服務于以下目標：便于用戶、分析人員和軟件設計人員進行理解和交流。支持目標軟件系統(tǒng)的確認?？刂葡到y(tǒng)進化過程。需求規(guī)格說明書的主體內容包括功能與行為需求描述以及非行為需求描述兩部分。需求規(guī)格說明書基本構架和內容見計算機軟件文檔編制規(guī)范（GB/T8567-2006）。4.1.6.1 需求

48、規(guī)格說明書的目標和內容4.1.6.2 需求評審 衡量需求規(guī)格說明書質量的標準按重要性次序排列為正確性、無歧義性、完全性、可驗證性、一致性、可理解性、可修改性和可追蹤性。正確性。需求規(guī)格說明書中的功能、行為、性能描述必須與用戶對目標軟件產品的期望相吻合。無歧義性。對于用戶、分析人員、設計人員和測試人員而言，需求規(guī)格說明書中的任何語法單位只能有唯一的語義解釋。完全性。需求規(guī)格說明書不能遺漏任何用戶需求?？沈炞C性。對于規(guī)格說明書中的任何需求，均應該對技術和經濟上的可行性手段進行驗證和確認。一致性。需求規(guī)格說明書的各部分內容之間不能相互矛盾?？衫斫庑浴Ｗ非笊鲜瞿繕瞬粦恋K需求規(guī)格說明書對于用戶、設計人

49、員和測試人員的易理解性?？尚薷男浴Ｐ枨笠?guī)格說明書的格式和組織方式應保證能夠比較容易地接納后續(xù)的增刪改，并使修改后的說明書能夠較好地保持其他各項屬性。可追蹤性。需求規(guī)格說明書分析后獲得的每項需求必須與用戶的原始需求項清晰地聯(lián)系起來，并為后續(xù)開發(fā)和其他文檔引用這些需求項提供便利。 4.2 面向數據流的結構化需求分析方法 結構化分析方法的雛形出現(xiàn)于20世紀60年代后期。但是，直到1979年才由DeMarco將其作為一種需求分析方法正式提出。20世紀80年代中后期，Ward & Hatley和Hatley & Pirbhai在結構化分析方法中引入了實時系統(tǒng)分析機制，Harel等人研制了面向復雜實時反應

50、式系統(tǒng)的開發(fā)環(huán)境STATEMATE. 結構化需求分析過程是通過建立三種模型來詮釋，它們分別是數據模型、功能模型和行為模型。4.2.1 實體-聯(lián)系圖 在數據模型中包含三種相互關聯(lián)的信息：數據對象、數據對象的屬性及數據對象彼此間相互連接的關系。4.2.1.1 數據對象 數據對象可以是外部實體（例如產生或使用信息的任何事物）、事物（例如報表）、行為（例如打電話）、事件（例如響警報）、角色（例如教師、學生、經理、雇員等）、單位（例如會計科）、地點（例如倉庫）或結構（例如文件）等?？傊梢杂梢唤M屬性來定義的實體都可以被認為是數據對象。 數據對象彼此間是有關聯(lián)的，例如，教師“教”課程，學生“學”課程.

51、數據對象只封裝了數據而沒有對施加于數據之上的操作加以引用，這是數據對象與面向對象范型中的“類”或“對象”的顯著區(qū)別。4.2.1.2 屬性 屬性定義了數據對象的性質。 應該根據對所要解決問題的理解，來確定特定數據對象的一組合適的屬性。4.2.1.3 聯(lián)系 客觀世界中的事物彼此間往往是有聯(lián)系的。 數據對象彼此之間相互連接的方式稱為聯(lián)系，也稱為關系。聯(lián)系可分為以下三種：一對一聯(lián)系（1：1）一對多聯(lián)系（1：N）多對多聯(lián)系（M：N）4.2.1.4 實體-聯(lián)系圖的符號 使用實體-聯(lián)系圖（Entity-Relationship Diagram）來建立數據模型?？梢园褜嶓w聯(lián)系圖簡稱為ER圖，相應地把用ER圖描

52、繪的數據模型稱為ER模型。4.2.1.5 數據規(guī)范化 常用“范式（Normal Forms）”定義消除數據冗余的程度。第一范式（1 NF）數據冗余程度最大，第六范式（6 NF）冗余程度最小。從實用角度來看，在大多數場合選用第三范式比較恰當。1.第一范式 無重復的列。2.第二范式 完全依賴于主鍵消除非主屬性對主鍵的部分函數依賴。 3.第三范式 不依賴于其它非主屬性消除傳遞依賴。4.2.2 狀態(tài)轉換圖 狀態(tài)轉移圖（簡稱為狀態(tài)圖）通過描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉換的事件來表示系統(tǒng)的行為。4.2.2.1 狀態(tài) 狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式，一個狀態(tài)代表系統(tǒng)的一種行為模式。狀態(tài)規(guī)定了系統(tǒng)對事件

53、的響應方式。 在狀態(tài)圖中定義的狀態(tài)主要有：初態(tài)（即初始狀態(tài)）、終態(tài)（最終狀態(tài)）和中間狀態(tài)。在一張狀態(tài)圖中只有一個初態(tài)，而終態(tài)則可以有0至多個。4.2.2.2 事件 事件是在某個特定時刻發(fā)生的事件，它是對引起系統(tǒng)做動作或（和）從一個狀態(tài)轉換到另一個狀態(tài)的外界事件的抽象。4.2.2.3 符號 在狀態(tài)圖中，初態(tài)用實心圓表示，終態(tài)用一對同心圓（內圓為實心圓）表示。 中間狀態(tài)用圓角矩形表示，可以用兩條水平橫線分成上、中、下3個部分。上面部分為狀態(tài)的名稱，這部分不能缺?。恢虚g部分為狀態(tài)變量的名字和值，此部分可選；下面部分是活動表，這部分也是可選。 活動表的語法格式為：事件名（參數表）/動作表達式。 狀態(tài)圖

54、中兩個狀態(tài)之間帶箭頭的連線稱為狀態(tài)轉換，箭頭指明了轉換方向。 事件表達式的語法：事件說明【警戒條件】/動作表達式。圖4.2是狀態(tài)圖中使用的主要符號表征。4.2.2.4 舉例4.2.3 數據流圖 數據流圖（Data Flow Diagram，DFD）是一種圖形化技術，它描繪信息流和數據從輸入移動到輸出的過程所經受的變換。4.2.3.1 符號數據存儲和數據流都是數據，僅僅所處的狀態(tài)不同。 處理并不一定是一個程序。一個處理框可以代表一系列程序、單個程序或者程序的一個模塊；它甚至可以代表用穿孔機穿孔或目視檢查數據正確性等人工處理過程。一個數據存儲也并不等同于一個文件，它可以表示一個文件、文件的一部分、

55、數據庫的元素或記錄的一部分等。 如圖4.4（a）所示，數據流圖有4種基本符號：正方形（或立方體）表示數據的源點或終點；圓角矩形（或圓形）代表變換數據的處理；開口矩形（或兩條平行橫線）代表數據存儲；箭頭表示數據流，即特定數據的流動方向。注意，數據流與程序流程圖中用箭頭表示的控制流有本質不同，不可以混淆。數據流圖的基本要點是描繪“做什么”，而不考慮“怎樣做”。4.2.3.2 數據流層次 在分析的初始，整個信息處理系統(tǒng)可以用圖4.5所示的頂級（第0級）數據流圖表示。 隨著需求分析活動的逐漸深入，較高層抽象級別的復雜轉換可以精化為一系列相互關聯(lián)的數據流和子轉換。 在進行逐層精化的過程中，必須維持層次間

56、數據流圖的平衡，被完成精化的轉換的輸入流、輸出流必須與精化它的數據流子圖的初始輸入流和最終輸出流保持嚴格一致。4.2.3.3 數據字典通常，數據字典的每一數據條目包含以下內容：（1）在數據流圖中標識數據流、數據源或外部實體的名稱與別名；（2）數據類型；（3）所有以它作為輸入流或輸出流的轉換列表；（4）如何使用該數據條目的簡要說明；（5）數據條目的解釋性說明；（6）其他補充說明，例如取值范圍與缺省值，有關的設計約束等。 數據條目的定義必須遵循精確、簡潔的原則，并且能為用戶方和軟件開發(fā)方共同理解。例如，可以使用形式語言中的語法定義機制描述數據條目的內容：=定義為（等價于）；A+B 表示語法成分A、

57、B的順序連接；A|B表示A或B；（）表示括弧內的內容可選（圓括弧里的分量可有可無）。A表示A0|A，即含有一個A，或者不含；An(n0)表示n個A的順序連接；常常使用上限和下限進一步注釋表示重復的花括弧。一種注釋方法是在開括弧的左邊用上角標和下角標分別表明重復的上限和下限；另一種注釋方法是在開括弧左側標明重復的下限，在閉括弧的右側標明重復的上限。例如：1A5，或者，它們含義相同。表示用A表示的字符串集合，字符串包括：A、AA、AAA、AAAA和AAAAA。 這樣，“家庭保安系統(tǒng)”中的“電話號碼”數據條目可以定義如下：電話號碼=分機號|外線號碼分機號=8601|8602|8699外線號碼=9+市

58、話號碼|長話號碼長話號碼=0+區(qū)號+市話號碼區(qū)號=30|1|93市話號碼=局號+分局號局號=455|448|888|552分局號=40|1|944.2.3.4 基于數據流的分析方法 數據流圖是目標軟件系統(tǒng)中各個處理子功能以及它們之間的數據流動的圖形表示。數據流圖的精化過程實際上是處理子功能和數據流的細化過程。隨著這一過程的進行，用戶需求逐步精確化、一致化和完全化。 在創(chuàng)建用戶需求的數據流模型的過程中， 分析人員應遵循以下規(guī)則： 首先建立頂級數據流圖4.2.3.4.1 創(chuàng)建數據流 對用戶需求的文字描述進行語法分析，其中的名詞和名詞短語構成潛在的外部實體、數據源或數據流，動詞構成潛在的處理功能。

59、采用通常的功能分解法，按照“高內聚、低耦合”原則逐個對處理功能進行精化；與此同時，逐步完成數據流的精化，并針對被精化的處理功能生成下一級數據流圖。 “高內聚、低耦合”原則是指，被分解出來的各子功能之間的聯(lián)系相對松散、簡單，子功能內部各部分的聯(lián)系相對緊密、復雜。 對數據流的精化包含兩方面的意義。首先，伴隨著功能分解的進行，數據流的內容及各項特征將逐步彰顯，所以要將其作為數據字典的一個條目，并不斷精化、調整內容。其次，在父數據流圖中的復合數據項可被分解為子數據項，這種數據流分解并不違背平衡準則。 在精化過程中必須維持各級數據流的平衡。 精化過程應適可而止，避免涉及軟件設計細節(jié)。一般來說 ，如果某子

60、功能可以用一段簡潔、精確的文字描述清楚，就無需進一步分解。4.2.3.4.2 過程規(guī)格說明 圖4.8中“口令核對”子功能分解出來的“設置口令”子功能可描述如下：參數：口令；類別：字符串；處理步驟：i. 檢查系統(tǒng)是否已有口令。若有，則驗證用戶輸入口令的有效性。若有效，則顯示提示信息要求輸入新口令；否則，顯示失敗信息并退出。ii. 檢查口令長度是否合法。若非法，則顯示提示信息，要求重新輸入。iii. 要求用戶再次鍵入合法口令，以便用戶確認和記憶。若兩次鍵入的口令不符，則返回。iv. 將確認后的口令按某種加密方法轉換為另一字符串存放于系統(tǒng)配置文件中。顯示成功信息并退出。約束條件：在上述i、ii、ii