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