【文章內容簡介】 關建模技術之間的最重要區(qū)別在于他們是構成系統的外部模型還是構成系統的內部模型。 表 建模技術對比 外部建模 內部建模 功能的 結構的 黑盒 白盒 行為的 非行為的 外部模型 外部模型可進一步劃分為建模系統外觀的模型和建模系統行為的抽象模型。 表示建模 表示模型是對系統外觀進行的模仿，相當于描述可見的輸出，最有效的表示法通常是畫圖。這種技術特有的優(yōu)點是易于獲得工具支持、模糊性低、不易出錯和可理解性高。對軟件系統定義而言，它并不是全部的內容，只是一個從中起著有效作用的基本元素。 原型法 原型在其他工程領域有著歷史悠久的傳統，但在軟件工程中，使用原型是最近幾年的事情。合算的開發(fā)原型需要相對強有力的開發(fā)平臺，好在現在已 經沒有了技術障礙，原型開發(fā)得到了快速的采用。原型可以為各種目的而購造，與需求工程相關的是那些試圖繪制所需系統的外觀和一些可能的行為的原型。 對原型一個普遍認同的分類： 探索性原型 —— 幫助需求獲取或細化需求，也稱為一次性原型，一旦需求工程完成后，它便沒有用處。 定義原型 —— 形成部分所需行為的定義，即部分規(guī)格說明。 建模技術 11 結構原型 —— 用于評價可能的內部設計方案，例如檢查性能。雖然是用于設計階段，但也用于需求階段可行性的檢查。 演化原型 —— 通過逐步求精過程，原型最終成為了產品。 需求工程主要關注的是前兩種原型，原型開發(fā) 隱含著迭代。如在需求獲取中：初始原型將向用戶演示，獲得的反饋將用于細化原型，在實踐中這種迭代會出現好幾次。迭代中可能會增加新內容，也可能減少內容。 原型在需求工程中主要作用是對用戶接口進行建模，尤其是當這些接口相當復雜、關鍵、新鮮時。原型開發(fā)的一個潛在好處是：可以促進潛在用戶的參與和客戶的承諾，但有個副作用：真實原型的早期外觀會誤導人們認為該項目比實際情形先進得多，隨著最終產品的出現就會感到失望。 行為（功能）建模 行為模型只是系統行為的抽象。 行為建模有很多種，我們就較一般的可能用到的簡單介紹幾 個 ： 1. 功能聲明與分解 功能聲明也許是最簡單、常用的行為定義技術。聲明使用文本方式，描述輸入和輸出之間的因果關系。功能分解可以說是一種高級策略，通過許多其他方式實現，如 UseCase 、 DFD 、結構圖?；舅枷胂喈敽唵?，通常系統功能性的詳細定義是按層次結構來實現的，即通過把功能分解為若干低層的、更為詳細的功能集。該技術也稱為功能求精或功能組合。 2. 任務分析 任務分析，涉及的是人的任務性能的分析或外部設計，特別用于人機接口（ HMI）。任務分析從人們所希望獲得的目標開始。任務是獲得這些目標的高級機制 ，操作是實現任務的交互。 3. 用例與腳本 用例（ usecase）描述所設計的解系統與一個或多個端子之間的某種特定的交互。 用例在面向對象領域主要作為一種分析和規(guī)格說明的技術。對新系統將投入使用的環(huán)境進行分析相當于研究該系統所必須滿足的要求。事實上，情形可能是客戶和潛在用戶確實發(fā)現用例易于理解，因此，用例就有助于客戶 /用戶與開發(fā)建模技術 12 者之間的交流。大多數用例都有“執(zhí)行者”，可以是人，也可能是系統的軟硬件設施。用例文檔可以用文本或 UML 圖來描述。用例的應用和構造具有相當大的靈活性，人們可能認為它不夠嚴格，但 是 應用 指定的 合適的指導原則可以解決這個問題。 4. 有限狀態(tài)機 有限狀態(tài)機（ Finite State Machines， FSM）通過輸入與輸出之間的因果關系對系統的行為進行建模。 (1) 系統可看作有若干個相互區(qū)別的穩(wěn)定狀態(tài)； (2) 當條件改變時，系統從一個狀態(tài)改變到另一個狀態(tài)； FSM 的設計規(guī)則 ? 轉移總是起始于一個狀態(tài)并終止于一個狀態(tài)。 ? 一個轉移總是有一個相關的觸發(fā)器。 ? 一個轉移可以有一個或多個相關動作。 ? 同一個觸發(fā)器可能對多個狀態(tài)有效。 內部模型 內部模型是對系統內部的構造或體系結構的建模技術 。可以很簡單的 把 解 系統的內部分成兩方面：數據和操作。 根據建模所側重的方面，可以劃分為三種內部建模技術。 1. 面向處理技術 抽象的把所考慮的系統建模成一組通信子系統，重點放在它們實施的處理上。 (1) 通信并發(fā)處理 這個模型把子系統看成是并行運行的，現實世界中的各種事物也是通常是如此的，因此 它 具有相當的直觀性。最常采用的方法是“數據流圖”，即 DFD。DFD 的開發(fā)需要大量的專門知識，以消除建模中可能導致的二義性和錯誤。好的 DFD 后面的解釋是較為直觀的，因而可理解性是比較良好的。 以下規(guī)則可以用來檢查 DFD 的有效性： ? 數據不能直接在數據存儲之 間流動； ? 數據在端子之間的流動不顯示； 建模技術 13 ? 處理和數據存儲通常至少有一個輸入和一個輸出。 (2) 通信順序處理 雖然真實事物一般都是 一個 并行的系統， 就 如 同 一個人可 以同時做很多事情一樣。但是，大部分計算機以順序的方式處理，特別的 在 軟件 設計的時候（即使是面向對象設計）。 對通信順序處理建模的常用表示法有樹狀圖或結構圖，另一種主要方法是偽碼。 2. 面向數據結構的技術 數據結構建模是 所有 信息系統最重要的 技術 ， 也 常稱為數據分析，關注的是靜態(tài)數據的結構。 實體屬性關系建模 ，則是數據庫應用系統的通用方法。 當進行數據分析時，通常起 始點是搜索需求獲取記錄，選出候選實體。識別有意義實體的好方法是問問：“哪些相關信息與這個實體相聯系？”。 與實體相關聯的信息即為實體的屬性。實體間的關系有三種：一對一，一對多，多對多。 3. 處理 /數 據相結合 該技術集中在對發(fā)生的處理和處理的數據的建模上，采用了一種完整的觀點，卻抽象更加復雜。 主要的兩種模型是實體生命歷史（ ELH） 和面向對象建模。 實體生命歷史建模起的是輔助性的作用，它從數據分析和數據流建模繼續(xù)而來，實體來自于 ERD，實體處理來自 DFD，然后為每個實體的有關處理順序進行建模。 ELH 的作用是在其他模型 之間充當一個交叉的檢查和一種集成。 面向對象建模把所考慮的系統建模為一組相互通信的對象。一個對象是存儲數據和對其數據上的操作進行抽象。 識別和定義對象只是一部分工作。還必須探討對象間的關系。 選擇技術 可以從兩個方面來選擇技術： 1. 特定的目的需要什么技術 2. 特定的技術適合什么目的 特定的目的或許更多的需要我們去挖掘、思考，而熟悉各種技術的常見應用領域將會有很大幫助。 建模技術 14 表 常見應用領域表 上下文圖 問題框架 一次性原型 功能分解 用例 任務動作法 F S M D F D 結構圖 E R D E L H 面向對象 D D (B N F) 需求獲取 √ √ 問題域（ PD）概述 √ √ 問題域結構 √ √ √ PD 數據模型 √ √ √ I/O 問題數據 √ √ 子域行為 √ 子域狀態(tài) √ √ 功能需求 √ 性能需求 √ 約束 SS 外觀 √ I/O 解數據 √ SS 行為（ ER 動作） √ √ √ √ √ SS 狀態(tài) √ √ 定時 √ √ 需求分析實踐 15 第四章 需求分析實踐 項目介紹 在現有《中遠船員綜合管理信息系統》操作平臺的基礎上， 用不到一年的時間，設計開發(fā)中遠通用、技術先進、功能全面、人性化與智能化突出的“中遠船員信息系統”（以下簡稱 CSIS），同時建立起以集團為核心的，聯結各家系統的中遠船員信息管理網絡，在中遠系統內實現船員信息的高度共享。 按照系統功能劃 分，工作小組下設 7 個業(yè)務組，分別為調配管理組、證件培訓組、勞動工資組、工資核算組、費用報銷組、集團平臺組、船員平臺組。 （由于在做需求過程種，發(fā)現報銷與工資有很多相近之處，因此已經合二為一） 進度 20xx 年 4 月 – 6 月，完成系統需求調查； 20xx 年 7 – 8 月中旬，在前期需求調查基礎上，拿出系統設計初步方案； 20xx 年 8 月中旬 – 8 月底，征求各家單位對初步方案的意見，修訂方案； 20xx 年 912 月，進入系統實質開發(fā)階段，在此期間 還需反復征求各家單位意見。 需求調查階段分四個小組： 調配、工資、勞資、證培。我所在的小組是工資（包含報銷）。 獲取需求 需求獲取可能是軟件開發(fā)中最困難、最關鍵、最易出錯及最需要交流的方面。需求獲取只有通