《軟件需求分析》教學(xué)PPT

《軟件需求分析》教學(xué)PPT,軟件需求分析,軟件,需求,分析,教學(xué),PPT 第10章.模型驅(qū)動(dòng)方法主要內(nèi)容1.模型驅(qū)動(dòng)方法的作用2.面向目標(biāo)的方法3.基于場(chǎng)景的方法4.基于用例的方法1.模型驅(qū)動(dòng)方法的作用n指導(dǎo)和組織需求獲取行為的開展q模型可以用于指導(dǎo)后續(xù)需求獲取行為的開展 n整理和歸類需求獲取行為得到的信息 q模型是進(jìn)行信息整理和歸類的很好的框架依據(jù)n為詳細(xì)信息的分析提供背景基礎(chǔ)和上下文知識(shí) q模型驅(qū)動(dòng)方法則是側(cè)重于前期需求階段的方法，是傳統(tǒng)需求分析方法的一個(gè)很好的補(bǔ)充 n幫助組織需求文檔的結(jié)構(gòu) n作為需求驗(yàn)證的知識(shí)基礎(chǔ) q發(fā)現(xiàn)細(xì)節(jié)知識(shí)與模型內(nèi)容的偏差和錯(cuò)誤 q指導(dǎo)需求驗(yàn)證行為的開展 主要內(nèi)容1.模型驅(qū)動(dòng)方法的作用2.面向目標(biāo)的方法3.基于場(chǎng)景的方法4.基于用例的方法2.面向目標(biāo)的方法n目標(biāo)模型q目標(biāo)：是系統(tǒng)被開發(fā)的目的 n可以在不同的抽象層次上進(jìn)行描述 n它有著明確的定義方式 n功能目標(biāo)（Functional Goal）和非功能目標(biāo)（Non-functional Goal）q滿足型目標(biāo)（Satisfaction Goal）和信息型目標(biāo)（Information Goal）q安全目標(biāo)（Safety Goal）、性能目標(biāo)（Performance Goal）、可用性目標(biāo)（Usability Goal）等等 n軟目標(biāo)（Soft Goal）和硬目標(biāo)（Hard Goal）n實(shí)現(xiàn)目標(biāo)（Achieve Goal，又稱為終止目標(biāo)Cease Goal）、維護(hù)目標(biāo)（Maintain Goal，又稱為避免目標(biāo)Avoid Goal）和優(yōu)化目標(biāo)（Optimize Goal）2.面向目標(biāo)的方法n目標(biāo)模型q關(guān)系n目標(biāo)之間的鏈接目標(biāo)之間的鏈接 qSupport（又稱為Dependency）鏈接和Conflict鏈接 qAND和OR鏈接 qAND Contribution鏈接和OR Contribution鏈接 積極（Positive），消極（Negative）n目標(biāo)與其他需求模型元素的鏈接目標(biāo)與其他需求模型元素的鏈接 qAND Operationalization鏈接和OR Operationalization鏈接：連接目標(biāo)和操作 前置（pre-）、后置（post-）和觸發(fā)（trigger）操作 qContribution鏈接：連接目標(biāo)和場(chǎng)景等需求的描述元素 q普通鏈接：連接目標(biāo)和分析模型 qResponsibility鏈接：連接目標(biāo)和行為者 qDependency鏈接：鏈接目標(biāo)和任務(wù)、資源 2.面向目標(biāo)的方法n面向目標(biāo)方法的處理過程 q目標(biāo)的獲取目標(biāo)的獲取 n現(xiàn)狀和背景的分析n已有目標(biāo)的驗(yàn)證和細(xì)化 n基于場(chǎng)景的方法等等q目標(biāo)分析目標(biāo)分析 n建立系統(tǒng)的目標(biāo)模型 q目標(biāo)實(shí)現(xiàn)目標(biāo)實(shí)現(xiàn) n收集與目標(biāo)相關(guān)的需求信息，討論可能的候選解決方案，確定最終的系統(tǒng)詳細(xì)需求和解決方案 主要內(nèi)容1.模型驅(qū)動(dòng)方法的作用2.面向目標(biāo)的方法3.基于場(chǎng)景的方法4.基于用例的方法3.基于場(chǎng)景的方法n場(chǎng)景q具有重點(diǎn)描述真實(shí)世界的特征，它利用情景、行為者之間的交互、事件隨時(shí)間的演化等方式來(lái)敘述性的描述系統(tǒng)的使用 3.基于場(chǎng)景的方法n基于場(chǎng)景的方法3.基于場(chǎng)景的方法n場(chǎng)景方法的分類3.基于場(chǎng)景的方法n場(chǎng)景的形式：場(chǎng)景的表達(dá)模式 q描述（Description）n表示法的正規(guī)性 q非形式化語(yǔ)言、半形式化語(yǔ)言和形式化語(yǔ)言n媒介形式（Medium）q敘述性的自由文本、結(jié)構(gòu)化文本、強(qiáng)限制文本、表格、圖表、圖像等 q外觀n動(dòng)態(tài)、靜態(tài)、交互3.基于場(chǎng)景的方法n場(chǎng)景的內(nèi)容q主要關(guān)注點(diǎn) n關(guān)于現(xiàn)在的，關(guān)于未來(lái)的，關(guān)于解決方案的 q環(huán)境范圍 n系統(tǒng)內(nèi)部，系統(tǒng)外部，系統(tǒng)和環(huán)境的交互q抽象層次 n具體的、抽象的、混合的q覆蓋范圍 n功能需求，非功能需求 q粒度 n整個(gè)業(yè)務(wù)過程；某個(gè)任務(wù)的完成過程；某個(gè)交互行為的詳細(xì)處理步驟 q示例類型 n正常流程，異常流程 3.基于場(chǎng)景的方法n場(chǎng)景的目的q描述（descriptive）n需求的文檔化，n需求協(xié)商q探索（exploratory）n需求獲取 n需求建模與分析 q解釋（explanatory）n需求的驗(yàn)證 3.基于場(chǎng)景的方法n場(chǎng)景的生命周期3.基于場(chǎng)景的方法n場(chǎng)景方法的作用q組織需求獲取得到的信息；q幫助進(jìn)行詳細(xì)的需求分析；q結(jié)合面向目標(biāo)的方法，指導(dǎo)需求獲取活動(dòng)的開展；主要內(nèi)容1.模型驅(qū)動(dòng)方法的作用2.面向目標(biāo)的方法3.基于場(chǎng)景的方法4.基于用例的方法4.基于用例的方法n用例q相關(guān)場(chǎng)景集合的敘述性的文本描述 qUML以用例來(lái)捕獲系統(tǒng)的功能需求，而不是所有的系統(tǒng)需求 4.基于用例的方法用例的描述ID:用例的標(biāo)識(shí)，通常會(huì)結(jié)合用例的層次結(jié)構(gòu)使用X.Y.Z的方式名稱:對(duì)用例內(nèi)容的精確描述，體現(xiàn)了用例所描述的任務(wù)，通常是“動(dòng)詞名詞”用例屬性包括創(chuàng)建者、創(chuàng)建日期、更新歷史等參與者:描述系統(tǒng)的主參與者、輔助參與者和每個(gè)參與者的目標(biāo)描述:簡(jiǎn)要描述用例產(chǎn)生的原因，大概過程和輸出結(jié)果優(yōu)先級(jí):用例所描述的需求的優(yōu)先級(jí)觸發(fā)條件:標(biāo)識(shí)啟動(dòng)用例的事件，可能是系統(tǒng)外部的事件，也可能是系統(tǒng)內(nèi)部的事件，還可能是正常流程的第一個(gè)步驟前置條件:用例能夠正常啟動(dòng)和工作的系統(tǒng)狀態(tài)條件后置條件:用例執(zhí)行完成后的系統(tǒng)狀態(tài)條件正常流程:在常見和符合預(yù)期的條件下，系統(tǒng)與外界的行為交互序列分支流程:用例中可能發(fā)生的非常見的其他合理場(chǎng)景異常流程:在非預(yù)期的錯(cuò)誤條件發(fā)生時(shí)，系統(tǒng)對(duì)外界進(jìn)行響應(yīng)的交互行為序列相關(guān)用例:記錄和該用例存在關(guān)系的其他用例。關(guān)于用例之間的關(guān)系見10.4.4業(yè)務(wù)規(guī)則:可能會(huì)影響用例執(zhí)行的業(yè)務(wù)規(guī)則特殊需求:和用例相關(guān)的其他特殊需求，尤其是非功能性需求假設(shè):在建立用例時(shí)所做的假設(shè)待確定問題:一些當(dāng)前的用例描述還沒有解決的問題4.基于用例的方法用例文檔本章小結(jié)n模型驅(qū)動(dòng)方法是基于模型的建立和使用而提出的方法，它在整個(gè)需求工程，甚至軟件工程中都可以發(fā)揮重要的作用q面向目標(biāo)的方法n目標(biāo)的概念將會(huì)對(duì)需求工程產(chǎn)生重要的影響q基于場(chǎng)景的方法n在軟件工程當(dāng)中有著極為廣泛的應(yīng)用q基于用例的方法n是最為常用的一種基于場(chǎng)景的方法n模型驅(qū)動(dòng)方法雖然已經(jīng)得到了相當(dāng)廣泛的應(yīng)用，但是它們?nèi)匀辉诓粩嗟陌l(fā)展和完善第十一章.需求分析概述主要內(nèi)容1.需求分析的根本任務(wù)1.建立分析模型2.建立解決方案2.需求分析技術(shù)3.需求分析方法4.前期需求階段的建模與分析5.需求分析的活動(dòng)1.需求分析的根本任務(wù)1.需求分析的根本任務(wù)n建立分析模型q將復(fù)雜的系統(tǒng)分解成為簡(jiǎn)單的部分以及它們之間的聯(lián)系，確定本質(zhì)特征q和用戶達(dá)成對(duì)信息內(nèi)容的共同理解q分析的活動(dòng)主要包括識(shí)別、定義和結(jié)構(gòu)化，它的目的是獲取某個(gè)可以轉(zhuǎn)換為知識(shí)的事物的信息1.需求分析的根本任務(wù)n創(chuàng)建解決方案q將一個(gè)問題分解成獨(dú)立的、更簡(jiǎn)單和易于管理的子問題來(lái)幫助尋找解決方案q創(chuàng)建解決方案的過程是創(chuàng)造性的q幫助開發(fā)者建立問題的定義，并確定被定義的事物之間的邏輯關(guān)系n這些邏輯關(guān)系可以形成信息的推理，進(jìn)而可以被用來(lái)驗(yàn)證解決方案的正確性。1.1建立分析模型n模型模型 q“模型是對(duì)事物的抽象，幫助人們?cè)趧?chuàng)建一個(gè)事物之前可以有更好的理解”q集中關(guān)注問題的計(jì)算特性（數(shù)據(jù)、功能、規(guī)則等等）q“它是對(duì)系統(tǒng)進(jìn)行思考和推理的一種方式。建模的目標(biāo)是建立系統(tǒng)的一個(gè)表示，這個(gè)表示以精確一致的方式描述系統(tǒng)，使得系統(tǒng)的使用更加容易”q建模方法n抽象n分解n投影1.1建立分析模型n抽象（Abstraction）q一方面要求人們只關(guān)注重要的信息，忽略次要的內(nèi)容n通過強(qiáng)調(diào)本質(zhì)的特征，就減少了問題的復(fù)雜性q另一方面也要求人們將認(rèn)知保留在適當(dāng)?shù)膶哟?，屏蔽更深層次的?xì)節(jié)n在問題的各元素之間推斷出更廣泛和更普遍的關(guān)系，幫助人們尋找解決方案n分解（Decomposition/Partitioning）q“分而治之”n將單個(gè)復(fù)雜和難以理解的問題分解成多個(gè)相對(duì)更容易的子問題，并掌握各子問題之間的聯(lián)系q分解的方案往往還能提供問題的解決思路n投影（Projection）q多視點(diǎn)方法1.1建立分析模型n計(jì)算世界與計(jì)算模型q使用軟件的構(gòu)成單位作為模型的組元q軟件構(gòu)建單位之間的關(guān)系作為模型組元之間的關(guān)系n基于計(jì)算科學(xué)建立的，具有形式化的特征q信息的描述具有明確化、準(zhǔn)確化和確定化的特征n需求分析階段不適宜建立形式化的計(jì)算模型q重點(diǎn)是問題，缺乏和軟件實(shí)現(xiàn)相關(guān)的技術(shù)細(xì)節(jié)q用戶無(wú)法理解1.1建立分析模型n問題世界與業(yè)務(wù)模型q使用問題域中的重要概念作為模型的組元q使用概念之間的業(yè)務(wù)聯(lián)系作為組元之間的關(guān)系n使用了業(yè)務(wù)描述的方式，具有非形式化特征q業(yè)務(wù)模型元素（即業(yè)務(wù)概念和業(yè)務(wù)聯(lián)系）的選取和定義上具有不準(zhǔn)確、不確定和模糊化q可以抽取出需求信息中最重要和最本質(zhì)的內(nèi)容q可以達(dá)成用戶和開發(fā)者的共同理解n非形式化特征使得它不適合于進(jìn)行需求建模q不足以用于描述一個(gè)有效的軟件解決方案n不準(zhǔn)確、不確定和模糊化1.1建立分析模型n軟件分析模型q介于計(jì)算模型和業(yè)務(wù)模型二者之間的模型形式q使用了計(jì)算模型的組元形式q在組元的表現(xiàn)上采用了業(yè)務(wù)模型的表現(xiàn)方式n半形式化的q不像計(jì)算模型那么嚴(yán)謹(jǐn)q比業(yè)務(wù)模型更嚴(yán)格1.1建立分析模型n三種模型1.1建立分析模型n模型的描述q三個(gè)要素之間互為依賴，每個(gè)要素都為下一個(gè)要素提供了一個(gè)必需的環(huán)境n語(yǔ)法：使用規(guī)則怎樣使用模型的元素，并且以什么方式組織、連接或關(guān)聯(lián)這些元素；n語(yǔ)義：特定模型元素所具有的含義；n語(yǔ)用：模型元素的上下文，以及影響該模型元素意義的約束和假定n分析模型q語(yǔ)用復(fù)雜q語(yǔ)義豐富q語(yǔ)法嚴(yán)格同時(shí)又不太復(fù)雜曾經(jīng)有很多的研究者嘗試建立一種能夠描述軟件開發(fā)中各種情景的形式化或半形式化模型語(yǔ)言，但最后都失敗了1.1建立分析模型n模型的描述q多視點(diǎn)方法1.1建立分析模型n視點(diǎn)（Viewpoints）：將系統(tǒng)中既交織共存又相對(duì)獨(dú)立的不同內(nèi)容拆解成不同的部分q每一個(gè)視點(diǎn)都是獨(dú)立的模型存在，用獨(dú)立的模型語(yǔ)言和表示法進(jìn)行描述n多視點(diǎn)：所有視點(diǎn)的模型描述集成起來(lái)，就是對(duì)原有復(fù)雜系統(tǒng)的模型描述q依據(jù)系統(tǒng)內(nèi)不同部分之間的關(guān)系，建立不同模型內(nèi)元素之間的聯(lián)系，從而將多個(gè)獨(dú)立的模型描述在語(yǔ)義上連接起來(lái)1.1建立分析模型模型、模型語(yǔ)言與表示法 1.1建立分析模型n需求建模q通常的做法是：n先依據(jù)獲取的問題域信息建立初步的模型。n然后分析用戶需求，對(duì)模型進(jìn)行調(diào)整，得到一個(gè)中間形式的模型形式。n最后，對(duì)調(diào)整后的模型進(jìn)行邏輯推理和驗(yàn)證，如果符合預(yù)期的期望，那么它就是最終的解決方案模型。1.2 建立解決方案需求分析的目標(biāo)1.2 建立解決方案建立解決方案的過程主要內(nèi)容1.需求分析的根本任務(wù)2.需求分析技術(shù)1.常用需求分析技術(shù)2.需求分析技術(shù)的發(fā)展過程3.Wieringa框架4.Zachman 框架3.需求分析方法4.前期需求階段的建模與分析5.需求分析的活動(dòng)2.1 常用需求分析技術(shù)n結(jié)構(gòu)化技術(shù)q數(shù)據(jù)建模n實(shí)體關(guān)系圖Entity Relationship Diagramq過程建模n數(shù)據(jù)流圖Data Flow Diagramn上下文圖Context Diagramn微規(guī)格說明Mini-Specificationn數(shù)據(jù)字典Data Dictionaryq行為建模n狀態(tài)(轉(zhuǎn)換)圖/矩陣State(Transition)Diagram/Matrixq過程/數(shù)據(jù)關(guān)系建模n功能實(shí)體矩陣Function/Entity Matrixq信息工程方法n功能分解圖Function Decomposition Diagramn過程依賴圖Process Dependency Diagramn面向?qū)ο蠹夹g(shù)qUMLn用例圖Use-Case Diagramn類圖Class Diagramn交互圖（順序圖/通信圖）Interaction（Sequence/Communication）Diagramn活動(dòng)圖Activity Diagramn對(duì)象約束語(yǔ)言O(shè)bject Constraint Languagen狀態(tài)圖State Chart DiagramNext2.1 常用需求分析技術(shù)n技術(shù)的綜合運(yùn)用q如何為各個(gè)視角選擇需求分析技術(shù)？n每一種需求分析技術(shù)都有自己的特點(diǎn)，具有在應(yīng)用上的獨(dú)特性q如何實(shí)現(xiàn)它們之間的配合？n只有通過多種需求分析技術(shù)的有機(jī)結(jié)合與集成才能充分的描述復(fù)雜應(yīng)用2.2需求分析技術(shù)的發(fā)展過程2.3 Wieringa框架系統(tǒng)對(duì)外交互系統(tǒng)內(nèi)部交互功能式描述通信式描述行為式描述對(duì)交互的有用性的描述對(duì)交互中發(fā)生的信息交流情況的描述更小的交互相互之間形成的先后銜接與協(xié)作關(guān)系交互所涉及的系統(tǒng)或者系統(tǒng)部分的分解關(guān)系分解可以使得系統(tǒng)的對(duì)外交互轉(zhuǎn)換為系統(tǒng)的內(nèi)部交互形式2.3 Wieringa框架結(jié)構(gòu)化信息工程面向?qū)ο笸ㄓ闷渌獠抗δ芄δ芊纸鈭D用例圖狀態(tài)（轉(zhuǎn)移）圖/矩陣外部通信上下文圖用例圖交互圖外部行為過程依賴圖交互圖概念組元數(shù)據(jù)流圖DFD實(shí)體關(guān)系圖ERD功能實(shí)體矩陣實(shí)體生命歷史事件實(shí)體矩陣類圖數(shù)據(jù)字典對(duì)象角色模型組元功能對(duì)象約束語(yǔ)言微規(guī)格說明組元通信數(shù)據(jù)流圖DFD功能實(shí)體矩陣事件實(shí)體矩陣過程依賴圖交互圖組元行為實(shí)體生命歷史活動(dòng)圖狀態(tài)（轉(zhuǎn)移）圖/矩陣業(yè)務(wù)過程模型Petri網(wǎng)2.4 Zachman 框架2.4 Zachman 框架nZachman矩陣的行q目標(biāo)/范圍（規(guī)劃者視圖）n關(guān)心軟件系統(tǒng)的成本和效益，n對(duì)最終系統(tǒng)的規(guī)模、形式、位置空間以及基本目標(biāo)的粗略描述n規(guī)劃者視圖規(guī)定了項(xiàng)目的前景和范圍。q企業(yè)模型（所有者視圖）：n關(guān)心軟件系統(tǒng)會(huì)如何參與和幫助實(shí)際工作n對(duì)業(yè)務(wù)實(shí)體、業(yè)務(wù)過程以及它們與系統(tǒng)之間交互的描述n利用業(yè)務(wù)概念限定了系統(tǒng)的解決方案分析模型。q系統(tǒng)模型（設(shè)計(jì)師視圖）：n關(guān)注軟件系統(tǒng)應(yīng)該的需要以及設(shè)計(jì)方法的選擇限制n對(duì)軟件系統(tǒng)的基本功能和設(shè)計(jì)空間的描述體系結(jié)構(gòu)。2.4 Zachman 框架nZachman矩陣的行q技術(shù)模型（構(gòu)建者視圖）：n關(guān)注程序n對(duì)軟件系統(tǒng)當(dāng)中控制邏輯、算法、I/O控制以及其他各種具體技術(shù)細(xì)節(jié)的描述描述詳細(xì)設(shè)計(jì)的設(shè)計(jì)模型q組件模型（集成者視圖）：n關(guān)注組裝n對(duì)軟件系統(tǒng)的組件、接口以及編碼程序等內(nèi)容的描述q實(shí)際運(yùn)行的系統(tǒng)：n描述系統(tǒng)投入使用后的實(shí)際狀況和在運(yùn)行中的實(shí)際表現(xiàn)。2.4 Zachman 框架nZachman矩陣的列：q數(shù)據(jù)：對(duì)企業(yè)有重要意義的事物以及企業(yè)對(duì)這些事物的理解q功能：企業(yè)在業(yè)務(wù)中執(zhí)行的任務(wù)以及企業(yè)對(duì)任務(wù)的理解。q位置：組織活動(dòng)和軟件系統(tǒng)的地理分布，以及它們與組織的其他方面的關(guān)聯(lián)。q人：在軟件系統(tǒng)被引入后會(huì)涉及的人員和組織q時(shí)間：系統(tǒng)內(nèi)的事件-事件關(guān)聯(lián)之間的時(shí)間因素，表現(xiàn)為業(yè)務(wù)的規(guī)劃調(diào)度、系統(tǒng)的事件響應(yīng)和控制結(jié)構(gòu)。q動(dòng)機(jī)：該列針對(duì)的是企業(yè)建立目標(biāo)系統(tǒng)的動(dòng)機(jī)，揭示了企業(yè)的目標(biāo)、目的、業(yè)務(wù)規(guī)劃、知識(shí)架構(gòu)、思想路線和決策基礎(chǔ)。2.4 Zachman 框架ContextualConceptualLogicalPhysicalAs BuiltFunctioningContextualConceptualLogicalPhysicalAs BuiltFunctioningWhyWhyWhoWhoWhenWhenWhereWhereWhatWhatHowHowProject scopeAnalysis modelDesign modelCoded programApplication SystemPlaning*AnalysisDesignImplementationIntegrationData ModelingBehavior ModelingEvent ModelingBusiness RulesNetwork topologiesOrganizational structure modelingBusiness Model2.4 Zachman 框架2.4 Zachman 框架結(jié)構(gòu)化信息工程面向?qū)ο笸ㄓ闷渌麛?shù)據(jù)數(shù)據(jù)流圖DFD實(shí)體關(guān)系圖ERD數(shù)據(jù)流圖DFD實(shí)體關(guān)系圖ERD類圖數(shù)據(jù)字典對(duì)象角色模型功能上下文圖數(shù)據(jù)流圖DFD功能實(shí)體矩陣上下文圖數(shù)據(jù)流圖DFD功能實(shí)體矩陣功能分解圖過程依賴圖用例圖交互圖活動(dòng)圖對(duì)象約束語(yǔ)言微規(guī)格說明狀態(tài)（轉(zhuǎn)移）圖/矩陣業(yè)務(wù)過程模型網(wǎng)絡(luò)Map人員層次模型矩陣模型網(wǎng)狀模型時(shí)間實(shí)體生命歷史事件實(shí)體矩陣實(shí)體生命歷史事件實(shí)體矩陣狀態(tài)（轉(zhuǎn)移）圖/矩陣Petri網(wǎng)動(dòng)機(jī)對(duì)象約束語(yǔ)言微規(guī)格說明對(duì)象角色模型主要內(nèi)容1.需求分析的根本任務(wù)2.需求分析技術(shù)3.需求分析方法4.前期需求階段的建模與分析5.需求分析的活動(dòng)3.需求分析方法n傳統(tǒng)分析 q沒有方法(1950s)n依賴個(gè)體才智,依據(jù)個(gè)人習(xí)慣n缺乏結(jié)構(gòu)、不可重復(fù)、不可測(cè)量,冗長(zhǎng)、混亂、偏頗、無(wú)結(jié)構(gòu)等等n結(jié)構(gòu)化分析 q傳統(tǒng)結(jié)構(gòu)化分析(late 1960s),現(xiàn)代結(jié)構(gòu)化分析(late 1970s)n以數(shù)據(jù)流動(dòng)為中心，以DFD為核心技術(shù)，輔助ERD,STDq信息工程(late 1980s)n以數(shù)據(jù)知識(shí)結(jié)構(gòu)為基礎(chǔ)，ERD為核心技術(shù)，輔助DFD，STD,FDD,PDn面向?qū)ο蠓治觯?990s）q以對(duì)象為中心，以UML（類圖）為核心技術(shù)q以全面思想革新為理想，以承繼結(jié)構(gòu)化技術(shù)為現(xiàn)實(shí)3.需求分析方法n結(jié)構(gòu)化分析3.需求分析方法n面向?qū)ο蠓治鲋饕獌?nèi)容1.需求分析的根本任務(wù)2.需求分析技術(shù)3.需求分析方法4.前期需求階段的建模與分析5.需求分析的活動(dòng)4.前期需求階段的建模與分析4.前期需求階段的建模與分析n面向目標(biāo)的分析（Goal Oriented Analysis）n面向問題域的分析（Problem Domain Oriented Analysis）n領(lǐng)域分析（Domain Analysis）n企業(yè)建模（Enterprise Modeling）4.前期需求階段的建模與分析n面向問題域的分析q問題框架n特性n解決q框架分解與組合q基本思路n研究所有可能的問題域，從中發(fā)現(xiàn)一些重復(fù)出現(xiàn)的簡(jiǎn)單問題類型n分析每一種問題框架的特性，確定問題的理解和解決方法n將問題框架的建立和分類系統(tǒng)化，以簡(jiǎn)單的問題框架為基本單位，進(jìn)行復(fù)雜問題的分解4.前期需求階段的建模與分析n領(lǐng)域分析4.前期需求階段的建模與分析n企業(yè)建模主要用來(lái)理解組織的結(jié)構(gòu)、行為規(guī)則、目標(biāo)、重要成員的任務(wù)與職責(zé)、操縱的數(shù)據(jù)等等。企業(yè)建模利用企業(yè)的目標(biāo)、任務(wù)、策略、資源等來(lái)刻畫組織的行為，并依此來(lái)發(fā)現(xiàn)組織開發(fā)系統(tǒng)的目的，建立系統(tǒng)的業(yè)務(wù)需求主要內(nèi)容1.需求分析的根本任務(wù)2.需求分析技術(shù)3.需求分析方法4.前期需求階段的建模與分析5.需求分析的活動(dòng)5.需求分析的活動(dòng)5.需求分析的活動(dòng)需求細(xì)化n明確用戶需求的隱含因素 n將從問題域和業(yè)務(wù)的角度表述的用戶需求等價(jià)的轉(zhuǎn)化為從軟件和技術(shù)的角度表述的系統(tǒng)需求 n非功能需求也需要從高層次的表述方式轉(zhuǎn)化為一系列更加詳細(xì)和具體的需求表述 n需求細(xì)化也會(huì)發(fā)現(xiàn)新的細(xì)節(jié)需求n需求已經(jīng)得了充分的理解，并且開發(fā)者已經(jīng)可以著手為其進(jìn)行方案設(shè)計(jì)時(shí)停止細(xì)化過程 n細(xì)化后的需求應(yīng)該被一一的標(biāo)識(shí)和記錄下來(lái) 5.需求分析的活動(dòng)需求細(xì)化n需求的記錄q標(biāo)識(shí)符（ID），每一條需求都應(yīng)該能夠通過ID唯一的標(biāo)識(shí)自己。q源頭（Source），要能夠回溯到需求的源頭，例如特定的涉眾。q理由（Rational），需求被提出的目的。q優(yōu)先級(jí)（Priority），詳細(xì)情況見下一節(jié)。q成本（Cost），預(yù)估的實(shí)現(xiàn)成本。q風(fēng)險(xiǎn)（Risk），實(shí)現(xiàn)該需求的過程中可能帶來(lái)的風(fēng)險(xiǎn)。q可變性（Volatility），將來(lái)發(fā)生變化的可能性。5.需求分析的活動(dòng)確定需求優(yōu)先級(jí)n累計(jì)投票累計(jì)投票 n區(qū)域劃分區(qū)域劃分 q重要性。需求的不可或缺程度。q緊急性。需求的時(shí)間緊迫程度。q懲罰性。忽略需求會(huì)導(dǎo)致的懲罰程度。q成本。實(shí)現(xiàn)需求的代價(jià)。q風(fēng)險(xiǎn)。需求實(shí)現(xiàn)中可能產(chǎn)生的風(fēng)險(xiǎn)程度。5.需求分析的活動(dòng)確定需求優(yōu)先級(jí)nTop-NqN的取值是不受明確限制的，真正受限制的是Top-N個(gè)需求的實(shí)現(xiàn)代價(jià)總和n數(shù)據(jù)量化數(shù)據(jù)量化 5.需求分析的活動(dòng)需求協(xié)商n明確沖突的因素，避免情緒上的沖突 n明確沖突的解決空間 n確定最佳解決方案 本章小結(jié)n需求分析是需求工程中最為重要和核心的活動(dòng)，它對(duì)信息的建模是理解問題的關(guān)鍵，也是創(chuàng)建正確解決方案的關(guān)鍵n需求分析涉及很多的技術(shù)和方法，需求分析活動(dòng)的有效執(zhí)行需要分析人員能夠掌握并判定這些方法的選擇與使用n需求分析過程當(dāng)中會(huì)執(zhí)行很多的重要子活動(dòng)，它們的有效整合確保了整個(gè)需求分析工作的成功思考題1.分析“結(jié)構(gòu)化分析”和“面向?qū)ο蠓治觥钡倪^程，說明它們?yōu)槭裁炊奸_始于系統(tǒng)的邊界定義？2.“事件”和“事物”一直是進(jìn)行需求分析的一個(gè)重要思路，你對(duì)此如何評(píng)價(jià)？3.列舉面向?qū)ο蠓治龅母鞣N技術(shù)，說明它們是對(duì)結(jié)構(gòu)化分析技術(shù)的繼承和借鑒嗎？如果是，那么說明它們借鑒了哪些結(jié)構(gòu)化分析技術(shù)，如果不是，那么說明它們的數(shù)學(xué)基礎(chǔ)是什么？4.Wieringa框架和Zachman框架給了你什么啟示？5.結(jié)合實(shí)踐調(diào)查情況，評(píng)價(jià)一下各種建模技術(shù)在實(shí)踐中的重要性.第12章.過程建模主要內(nèi)容1.過程建模2.數(shù)據(jù)流圖DFD3.微規(guī)格說明4.數(shù)據(jù)字典5.模塊結(jié)構(gòu)圖6.DFD的類型1.過程建模結(jié)構(gòu)化建模n怎么理解復(fù)雜世界？q復(fù)雜簡(jiǎn)單（分解）n簡(jiǎn)單可理解性（最基本單位）n簡(jiǎn)單（高內(nèi)聚）n簡(jiǎn)單 VS 簡(jiǎn)單（低耦合）q簡(jiǎn)單復(fù)雜（接口和實(shí)現(xiàn)）n結(jié)構(gòu)化建模q復(fù)雜世界復(fù)雜處理過程（事情的發(fā)生發(fā)展）q簡(jiǎn)單過程（可表達(dá)的“函數(shù)”）n軟件“函數(shù)”、程序q復(fù)雜簡(jiǎn)單n功能分解結(jié)構(gòu)q簡(jiǎn)單復(fù)雜（函數(shù)調(diào)用）1.過程建模n結(jié)構(gòu)化建模q過程建模，數(shù)據(jù)建模n過程建模是結(jié)構(gòu)化建模的核心方法q系統(tǒng)是過程的集合q過程可以被分解為子過程q最終的子過程可以被映射為計(jì)算實(shí)體函數(shù)q所有的系統(tǒng)都是由過程構(gòu)建的n主要思想q用圖形的方式建立和描述良好的過程模型1.過程建模主要內(nèi)容1.過程建模2.數(shù)據(jù)流圖DFD1.基本元素2.規(guī)則3.層次結(jié)構(gòu)4.層次結(jié)構(gòu)的建立5.DFD的驗(yàn)證3.微規(guī)格說明4.數(shù)據(jù)字典5.模塊結(jié)構(gòu)圖6.DFD的類型2.1 DFD的基本元素n外部實(shí)體q外部實(shí)體是指處于待構(gòu)建系統(tǒng)之外的人、組織、設(shè)備或者其他軟件系統(tǒng)，它們不受系統(tǒng)的控制，開發(fā)者不能以任何方式操縱它們 q需要進(jìn)行建模的外部實(shí)體是那些和待構(gòu)建的軟件系統(tǒng)之間存在著數(shù)據(jù)交互的外部實(shí)體，它們是待構(gòu)建系統(tǒng)的數(shù)據(jù)源或者數(shù)據(jù)目的地q所有的外部實(shí)體聯(lián)合起來(lái)構(gòu)成了軟件系統(tǒng)的外部上下文環(huán)境 2.1 DFD的基本元素n過程q過程是指施加于數(shù)據(jù)的動(dòng)作或者行為，它們使得數(shù)據(jù)發(fā)生變化，包括被轉(zhuǎn)換（transformed）、被存儲(chǔ)（stored）或者被分布（distributed）q可能是由軟件系統(tǒng)控制的，也可能是由人工執(zhí)行的，它重在數(shù)據(jù)發(fā)生變化的效果而不是其執(zhí)行者 q可能會(huì)表現(xiàn)為不同的抽象層次 n內(nèi)容足夠細(xì)節(jié)和具體，能夠?qū)ζ渲苯舆M(jìn)行“編碼”處理的過程被稱為原始過程（Primitive Process，又稱為基本過程Elementary Process）2.1 DFD的基本元素n數(shù)據(jù)流q數(shù)據(jù)流是指數(shù)據(jù)的運(yùn)動(dòng)，它是系統(tǒng)與其環(huán)境之間或者系統(tǒng)內(nèi)兩個(gè)過程之間的通信形式 q數(shù)據(jù)流可以分割和組合 q數(shù)據(jù)字典和ERD通常被用來(lái)描述DFD數(shù)據(jù)流的詳細(xì)內(nèi)容 2.1 DFD的基本元素n數(shù)據(jù)存儲(chǔ) q數(shù)據(jù)存儲(chǔ)是軟件系統(tǒng)需要在內(nèi)部收集、保存，以供日后使用的數(shù)據(jù)集合 q數(shù)據(jù)存儲(chǔ)的詳細(xì)內(nèi)容通常也是用數(shù)據(jù)字典和ERD來(lái)進(jìn)行描述的2.1 DFD的基本元素示例：DeMarco2.1 DFD的基本元素示例：Gane-SarsonReturn2.2 規(guī)則n過程是對(duì)數(shù)據(jù)的處理，必須有輸入，也必須有輸出，而且輸入數(shù)據(jù)集和輸出數(shù)據(jù)集應(yīng)該存在差異XXXY2.2 規(guī)則n數(shù)據(jù)流是必須和過程產(chǎn)生關(guān)聯(lián)的，它要么是過程的數(shù)據(jù)輸入，要么是過程的數(shù)據(jù)輸出2.2 規(guī)則nDFD當(dāng)中所有的對(duì)象都應(yīng)該有一個(gè)可以唯一標(biāo)識(shí)自己的名稱。q過程使用動(dòng)詞q外部實(shí)體、數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)使用名詞2.3 層次結(jié)構(gòu)n依據(jù)所含過程的不同抽象程度，DFD可以在不同的抽象層次上進(jìn)行系統(tǒng)的描述n一個(gè)比較抽象的過程可以被展開為一個(gè)子過程更加具體的DFD圖nDFD的層次結(jié)構(gòu)q上下文圖q0層圖qN層圖（N0）2.3 層次結(jié)構(gòu)n上下文圖q將整個(gè)系統(tǒng)看做是一個(gè)過程，這個(gè)過程實(shí)現(xiàn)系統(tǒng)的所有功能，是系統(tǒng)功能的最高抽象 n上下文圖中存在且僅存在一個(gè)過程，表示整個(gè)系統(tǒng)。這個(gè)單一的過程通常編號(hào)為0 n上下文圖中需要表示出所有和系統(tǒng)交互的外部實(shí)體，并描述交互的數(shù)據(jù)流，包括系統(tǒng)輸入和系統(tǒng)輸出 n上下文圖中不會(huì)出現(xiàn)數(shù)據(jù)存儲(chǔ)實(shí)例 q它非常適合于描述系統(tǒng)的應(yīng)用環(huán)境、定義系統(tǒng)的邊界 2.3 層次結(jié)構(gòu)n0層圖q位于上下文圖下面一層，是上下文圖中單一過程的細(xì)節(jié)描述，是對(duì)該單一過程的第一次功能分解 q是整個(gè)系統(tǒng)的功能概圖 q0層圖應(yīng)該被描述的簡(jiǎn)潔、清晰，需求工程師要根據(jù)系統(tǒng)的復(fù)雜度掌握0層圖中過程的抽象程度q示例 2.3 層次結(jié)構(gòu)nN層圖q對(duì)0層圖的過程分解產(chǎn)生的子圖稱為1層圖，對(duì)N層圖的過程分解后產(chǎn)生的子圖稱為N+1層圖（N0），過程分解是可以持續(xù)進(jìn)行的，直至最終產(chǎn)生的子圖都是原始DFD圖q原始DFD圖可以進(jìn)一步展開為n微規(guī)格說明n數(shù)據(jù)字典q在低于0層圖的子圖上通常不顯示外部實(shí)體 2.4 層次結(jié)構(gòu)的建立n建立步驟1.創(chuàng)建上下文圖 2.發(fā)現(xiàn)并建立DFD片斷 3.根據(jù)DFD片斷組合產(chǎn)生0層圖；4.對(duì)0層圖的過程進(jìn)行功能分解，產(chǎn)生N層圖 2.4 層次結(jié)構(gòu)的建立1.創(chuàng)建上下文圖n在需求獲取階段獲得的業(yè)務(wù)需求以及業(yè)務(wù)需求所決定的項(xiàng)目前景與范圍可以用來(lái)幫助建立系統(tǒng)的上下文圖 2.4 層次結(jié)構(gòu)的建立2.發(fā)現(xiàn)并建立DFD片段nDFD片斷是系統(tǒng)對(duì)某個(gè)事件的響應(yīng)過程的DFD描述，它是為系統(tǒng)中發(fā)生的重要事件創(chuàng)建的。n它將系統(tǒng)對(duì)事件的處理看做是一個(gè)單一的過程，重點(diǎn)描述這個(gè)單一過程與事件外界（包括系統(tǒng)內(nèi)其他部分和系統(tǒng)外的外部實(shí)體）的數(shù)據(jù)流交互 2.4 層次結(jié)構(gòu)的建立3.產(chǎn)生0層圖n往往需要多次調(diào)整DFD片段的整合結(jié)果才能得出n對(duì)DFD圖（尤其是0層圖）質(zhì)量的判定有下面幾個(gè)準(zhǔn)則：q1、沒有語(yǔ)法錯(cuò)誤，遵守12.2.2所述的各項(xiàng)規(guī)則。q2、具有良好的語(yǔ)義，過程的功能設(shè)置要高內(nèi)聚、低耦合。q3、保持?jǐn)?shù)據(jù)一致性，過程的輸入流要足以產(chǎn)生數(shù)據(jù)輸出。同時(shí)過程的輸出流是在充分利用輸入數(shù)據(jù)的基礎(chǔ)上產(chǎn)生的，不存在輸入數(shù)據(jù)的浪費(fèi)。q4、控制復(fù)雜度，不要一次在圖中顯示太多的信息。一般情況下，一個(gè)圖中的過程數(shù)量最好控制在59（人腦的最佳信息處理量）個(gè)。而且圖中的數(shù)據(jù)流數(shù)量越少越好，越簡(jiǎn)潔越好（接口最小化）。2.4 層次結(jié)構(gòu)的建立4.功能分解產(chǎn)生N層圖n功能分解是一個(gè)拆分功能的描述，將單個(gè)復(fù)雜的過程變?yōu)槎鄠€(gè)更加具體、更加精確和更加細(xì)節(jié)的過程 n在功能分解過程當(dāng)中，最重要的是要保證分解過程的平衡性（Balance），它要求DFD子圖的輸入流、輸出流必須和父過程的輸入流、輸出流保持一致 2.4 層次結(jié)構(gòu)的建立4.功能分解產(chǎn)生N層圖n在分解產(chǎn)生的子圖為下述情景之一時(shí)，可以判定其為原始DFD圖，此時(shí)應(yīng)該停止持續(xù)的功能分解活動(dòng)：q所有過程都已經(jīng)被簡(jiǎn)化為一個(gè)選擇、計(jì)算或者數(shù)據(jù)庫(kù)操作；q所有數(shù)據(jù)存儲(chǔ)都僅僅表示了一個(gè)單獨(dú)的數(shù)據(jù)實(shí)體；q用戶已經(jīng)不關(guān)心比子圖更為細(xì)節(jié)的內(nèi)容，或者子圖的描述已經(jīng)詳細(xì)的足以支持后續(xù)的開發(fā)活動(dòng)；q每一個(gè)數(shù)據(jù)流都已經(jīng)不需要進(jìn)行更詳細(xì)的切分，以展示對(duì)不同數(shù)據(jù)的不同處理方式；q每一個(gè)業(yè)務(wù)表單、事務(wù)、計(jì)算機(jī)的屏幕顯示（computer on-line display）和業(yè)務(wù)報(bào)表都已經(jīng)被表示為一個(gè)單獨(dú)的數(shù)據(jù)流；q系統(tǒng)的每一個(gè)最低層菜單選項(xiàng)都能在子圖中找到獨(dú)立的過程。2.4 層次結(jié)構(gòu)的建立 示例n使用DFD描述常見的電梯控制系統(tǒng)。q一個(gè)控制系統(tǒng)控制多個(gè)電梯。每個(gè)電梯被置于一個(gè)相應(yīng)甬道之中，在卷?yè)P(yáng)電機(jī)的作用下在甬道內(nèi)做上下運(yùn)動(dòng)。甬道內(nèi)安裝有多個(gè)傳感器，通常每個(gè)電梯停靠點(diǎn)一個(gè)，用來(lái)感應(yīng)電梯的實(shí)時(shí)位置。電梯內(nèi)部和建筑的每個(gè)電梯停靠層都設(shè)置有指示器，用來(lái)告知用戶的電梯實(shí)時(shí)位置和運(yùn)動(dòng)狀況。電梯內(nèi)和建筑的每個(gè)電梯?？繉佣荚O(shè)有按鈕，用戶可以通過這些按鈕提出服務(wù)申請(qǐng)并進(jìn)出電梯。控制系統(tǒng)調(diào)度用戶的申請(qǐng)，讓電梯以最有效的方式滿足用戶的服務(wù)要求2.4 層次結(jié)構(gòu)的建立 示例：1.建立上下文圖2.4 層次結(jié)構(gòu)的建立 示例：2.建立DFD片段2.4 層次結(jié)構(gòu)的建立 示例：2.建立DFD片段2.4 層次結(jié)構(gòu)的建立 示例：3.建立0層圖2.4 層次結(jié)構(gòu)的建立 示例：3.建立0層圖2.4 層次結(jié)構(gòu)的建立 示例：4.功能分解建立N層圖n無(wú)2.5 DFD的驗(yàn)證n驗(yàn)證DFD的語(yǔ)法 q確保DFD中不會(huì)發(fā)生語(yǔ)法錯(cuò)誤 n驗(yàn)證DFD的結(jié)構(gòu) q驗(yàn)證DFD層次結(jié)構(gòu)之間的一致性 q驗(yàn)證DFD層次結(jié)構(gòu)說明的完備性 n驗(yàn)證DFD的語(yǔ)義 q確保DFD所說明內(nèi)容的正確性和準(zhǔn)確性 主要內(nèi)容1.過程建模2.數(shù)據(jù)流圖DFD3.微規(guī)格說明1.結(jié)構(gòu)化英語(yǔ)/偽碼2.行為圖3.決策表4.決策樹4.數(shù)據(jù)字典5.模塊結(jié)構(gòu)圖6.DFD的類型3.1 結(jié)構(gòu)化英語(yǔ)/偽碼n敘述上采用了結(jié)構(gòu)化程序語(yǔ)言的三種控制結(jié)構(gòu)：順序、條件決策和循環(huán)；n使用了一些類似于結(jié)構(gòu)化程序語(yǔ)言關(guān)鍵字的詞語(yǔ)來(lái)表明敘述的邏輯，例如IF、THEN、ELSE、DO、DO WHILE、DO UNTIL等等；n在格式上，使用和結(jié)構(gòu)化程序語(yǔ)言相同的縮進(jìn)方式來(lái)表明敘述的結(jié)構(gòu)。n簡(jiǎn)短語(yǔ)句，使用名詞和動(dòng)詞，避免使用容易產(chǎn)生歧義的形容詞和副詞 3.1 結(jié)構(gòu)化英語(yǔ)/偽碼n示例3.2 行為圖n結(jié)構(gòu)化英語(yǔ)的一種特殊表達(dá)方式，用特定的圖示來(lái)表示過程的邏輯結(jié)構(gòu) 3.2 行為圖示例3.3 決策表n條件聲明是進(jìn)行決策時(shí)需要參考的變量列表n條件選項(xiàng)是那些變量可能的取值n動(dòng)作聲明是決策后可能采取的動(dòng)作n動(dòng)作選項(xiàng)表明那些動(dòng)作會(huì)在怎樣的條件下發(fā)生 條件和行動(dòng)規(guī)則條件聲明（Condition Statement）條件選項(xiàng)（Condition Entry）行動(dòng)聲明（Action Statement）行動(dòng)選項(xiàng)（Action Entry）3.3 決策表示例條件和行動(dòng)規(guī)則account-typeNOWNOWREGULARREGULARdaily-balance=300=100set service-charge to$5Xset service-charge to$0XXset service-charge to greater of$3 or$.20 timesX3.4 決策樹n通常是一顆平放的樹，樹根在左邊，樹枝從左向右展開。樹枝上是有關(guān)條件和行動(dòng)的描述 主要內(nèi)容1.過程建模2.數(shù)據(jù)流圖DFD3.微規(guī)格說明4.數(shù)據(jù)字典5.模塊結(jié)構(gòu)圖6.DFD的類型4.數(shù)據(jù)字典n數(shù)據(jù)字典是一個(gè)儲(chǔ)存庫(kù)，包含軟件使用和產(chǎn)生的所有數(shù)據(jù)對(duì)象的描述，其中也包括DFD當(dāng)中數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)的定義 n有組織地列出DFD中的涉及的所有數(shù)據(jù)元素（數(shù)據(jù)流、數(shù)據(jù)存儲(chǔ)），并定義每個(gè)數(shù)據(jù)元素的q名稱q表示方法q單位/格式q范圍q使用地點(diǎn)q使用方法q其他描述信息 4.數(shù)據(jù)字典數(shù)據(jù)結(jié)構(gòu)描述n數(shù)據(jù)字典要求對(duì)數(shù)據(jù)元素（尤其是其結(jié)構(gòu)）的描述要精確、嚴(yán)格和明確 符號(hào)含義示例=包含，由構(gòu)成Name=first_name+last_name+指明序列結(jié)構(gòu)()內(nèi)容可選Phone_No.=(Area_No.)+Local_No.內(nèi)容多選一Number=0|1|2|3|4|5|6|7|8|9|分割內(nèi)部的多個(gè)選項(xiàng)nm循環(huán),最少n次,最多m次Area_No=3Number4數(shù)據(jù)存儲(chǔ)的標(biāo)識(shí)符(關(guān)鍵字)Student=ID+Name+.*注釋Area_No=3Number4*區(qū)號(hào)為3到4位數(shù)字4.數(shù)據(jù)字典數(shù)據(jù)結(jié)構(gòu)描述示例定義說明telephone no.=local extension|outside no.|0 local extension=30-93outside no.=9+service code|domestic no.service code=110|120|domestic no.=(area code)+local numberarea code=30-94local number=80-98電話號(hào)碼可能是內(nèi)線、外線或者轉(zhuǎn)接主機(jī)（撥0）內(nèi)線號(hào)碼是3位數(shù)字外線要先撥9，然后再撥特服號(hào)碼或普通電話號(hào)碼特服號(hào)碼有110、120、普通電話號(hào)碼為可選的區(qū)號(hào)加本地號(hào)區(qū)號(hào)是3到4位數(shù)字本地號(hào)是8位數(shù)字4.數(shù)據(jù)字典n數(shù)據(jù)字典為每個(gè)數(shù)據(jù)元素組織描述信息 名稱數(shù)據(jù)元素的原始名稱別名數(shù)據(jù)元素的其他名稱使用地點(diǎn)會(huì)使用該數(shù)據(jù)元素的過程使用方法該數(shù)據(jù)元素扮演的角色（輸入流、輸出流或者數(shù)據(jù)存儲(chǔ)等）使用范圍該數(shù)據(jù)元素存在的范圍描述對(duì)數(shù)據(jù)元素內(nèi)容的描述單位/格式數(shù)據(jù)元素的數(shù)據(jù)類型，可能事先設(shè)置的取值4.數(shù)據(jù)字典示例名稱telephone number別名phone number,number使用的地點(diǎn)和方法read-phone-number(input)display-phone-number(output)analyze-long-distance-calls(input)描述telephone no.=local extension|outside no.|0 local extension=30-93outside no.=9+service code|domestic no.service code=110|120|domestic no.=(area code)+local numberarea code=30-94local number=80-98格式alphanumeric data主要內(nèi)容1.過程建模2.數(shù)據(jù)流圖DFD3.微規(guī)格說明4.數(shù)據(jù)字典5.模塊結(jié)構(gòu)圖1.功能分解圖2.過程依賴圖6.DFD的類型5.1 功能分解圖n在一個(gè)圖內(nèi)自上至下的集中顯示系統(tǒng)的功能分解結(jié)構(gòu) q最頂層的單獨(dú)功能通常是對(duì)整個(gè)系統(tǒng)的使命描述，是對(duì)系統(tǒng)業(yè)務(wù)需求的概括 q系統(tǒng)使命說明的下一層被稱為功能的最頂層，描述了系統(tǒng)應(yīng)該具備的一些重要功能，它們支撐著系統(tǒng)使命的實(shí)現(xiàn) q功能最頂層下面的分支是對(duì)最頂層功能執(zhí)行分解后形成的層次關(guān)系 q最底層的是基本的業(yè)務(wù)功能。這些基本的業(yè)務(wù)功能是人們所能找到的最基本的、不可再細(xì)分的功能或處理n能夠更加集中、更加直觀的展示大量過程之間的層次關(guān)系 5.1 功能分解圖5.1 功能分解圖5.2 過程依賴圖n描述功能和過程之間的依賴關(guān)系 q數(shù)據(jù)依賴關(guān)系q資源依賴關(guān)系q約束依賴關(guān)系 主要內(nèi)容1.過程建模2.數(shù)據(jù)流圖DFD3.微規(guī)格說明4.數(shù)據(jù)字典5.模塊結(jié)構(gòu)圖6.DFD的類型6.DFD的類型6.DFD的類型本章小結(jié)n結(jié)構(gòu)化分析的主要方法是過程建模和數(shù)據(jù)建模，其中過程建模是其核心n過程建模以DFD為中心，結(jié)合使用微規(guī)格說明、數(shù)據(jù)字典、ERD、FDD、PDD等技術(shù)一起完成結(jié)構(gòu)化分析的建模任務(wù)nDFD建立在四種簡(jiǎn)單的元素之上，使用層次結(jié)構(gòu)表達(dá)了功能分解關(guān)系，它是一種簡(jiǎn)潔、易于理解和使用的技術(shù)，但是它較用于建模復(fù)雜系統(tǒng)第13章.數(shù)據(jù)建模主要內(nèi)容1.數(shù)據(jù)模型2.實(shí)體關(guān)系模型ERD3.ERD建模1.數(shù)據(jù)模型n數(shù)據(jù)模型q描述數(shù)據(jù)的定義、結(jié)構(gòu)和關(guān)系等特性的模型q說明了問題域和解系統(tǒng)共享的事物、對(duì)共享事物的描述和共享事物之間的關(guān)系 q能夠反映企業(yè)業(yè)務(wù)的核心知識(shí) n建立數(shù)據(jù)模型的過程被稱為數(shù)據(jù)建模q模型建立：ERDq數(shù)據(jù)規(guī)范化q面向?qū)ο蠓治鲋械念悎D也可以建立數(shù)據(jù)描述模型1.數(shù)據(jù)模型主要內(nèi)容1.數(shù)據(jù)模型2.實(shí)體關(guān)系模型ERD1.實(shí)體2.屬性3.關(guān)系3.ERD建模2.實(shí)體關(guān)系模型ERDn起源于Peter Chen1976年提出的實(shí)體關(guān)系建模方法 n沒有標(biāo)準(zhǔn)的表示法 n基本元素q實(shí)體q關(guān)系q屬性2.1 實(shí)體n實(shí)例（Instance）q需要在系統(tǒng)中收集和存儲(chǔ)的現(xiàn)實(shí)世界事物 n實(shí)體（Entity）q具有相同特征和屬性的實(shí)例集的類別描述 2.1 實(shí)體n概念實(shí)體n邏輯實(shí)體StudentStudentIDNameDOB2.1 實(shí)體n進(jìn)程實(shí)體q系統(tǒng)需要它們?cè)谀承r(shí)刻的快照或者它們的運(yùn)行環(huán)境信息n不是它們所體現(xiàn)出來(lái)的功能和達(dá)成的效果 選課時(shí)間地點(diǎn)選課人被選課程2.2 屬性n屬性q實(shí)體的描述特征。q以數(shù)字、代號(hào)、單詞、短語(yǔ)、文本乃至聲音和圖像的形式存在q一系列屬性的存在集成起來(lái)就可以描述一個(gè)實(shí)體的實(shí)例 n屬性是實(shí)體的特征，不是數(shù)據(jù)。屬性會(huì)以一定的形式存在，這種存在才是數(shù)據(jù)，被稱為屬性的值（Value）2.2 屬性n屬性的值就應(yīng)該是一個(gè)合法的或者有業(yè)務(wù)含義的值，這個(gè)合法的取值范圍稱為域（Domain）數(shù)據(jù)類型類型說明域例子Number整數(shù)最小最大月份的域：112Real實(shí)數(shù)最小最大考試得分：0.0100.0Text文本TEXT(屬性的最大長(zhǎng)度)電話號(hào)碼：TEXT（20）Date日期最早最晚出生日期：1900-01-01今天Time時(shí)間最早最晚Boolean布爾Enumeration枚舉值1、值n性別：男、女、未知Binary二進(jìn)制2.2 屬性n標(biāo)識(shí)符，又稱為鍵（Key）q可以被用來(lái)唯一的確定和標(biāo)識(shí)每個(gè)實(shí)例的屬性或者屬性組合n一個(gè)實(shí)體可能有多個(gè)鍵，都被稱為候選鍵（Candidate Key）q人們通常會(huì)從多個(gè)候選鍵中選擇和使用固定的某一個(gè)鍵來(lái)進(jìn)行實(shí)例的標(biāo)識(shí)q這個(gè)被選中的候選鍵被稱為主鍵（Primary Key）q沒有被選做主鍵的候選鍵被稱為替代鍵（Alternate Key）2.2 屬性n單值屬性和多值屬性 n簡(jiǎn)單屬性和組合屬性 n存儲(chǔ)屬性和導(dǎo)出屬性 2.3 關(guān)系n存在于一個(gè)或多個(gè)實(shí)體之間的自然業(yè)務(wù)聯(lián)系n所有的關(guān)系隱含地都是雙向的 n關(guān)系表達(dá)的不是實(shí)體物理上的聯(lián)系（例如車與車輪），而是邏輯上的鏈接（例如整體部分關(guān)系）2.3 關(guān)系n度數(shù)q參與關(guān)系的實(shí)體數(shù)量 2.3 關(guān)系n基數(shù)（約束）q最大基數(shù)（鍵約束Key Constraint）n對(duì)關(guān)系中任意的其他實(shí)體實(shí)例，該實(shí)體可能參與關(guān)系的最大數(shù)量 q最小基數(shù)（參與約束Participant Constraint）n對(duì)關(guān)系中任意的其他實(shí)體實(shí)例，該實(shí)體可能參與關(guān)系的最小數(shù)量 Sales Staff#Employee IDEmployee NameEmployee PhoneSales Organizational Structure#Manage ID#Subordinate ID#Team nameAssignment DatemanageReports to0:N0:N1:11:12.3 關(guān)系n子類型關(guān)系q在多個(gè)實(shí)體大部分相似、少部分不同時(shí)，可以從相似的實(shí)體當(dāng)中抽取共性，建立一個(gè)公共的超類型（Super-type），所有實(shí)體都是超類型的子類型 2.3 關(guān)系n被關(guān)系影響的實(shí)體q弱實(shí)體n指存在和標(biāo)識(shí)需要依賴于其他實(shí)體的實(shí)體 q關(guān)聯(lián)實(shí)體n實(shí)體間建立關(guān)系時(shí)的副產(chǎn)品 2.ERD表示法2.ERD表示法主要內(nèi)容1.數(shù)據(jù)模型2.實(shí)體關(guān)系模型ERD3.ERD建模1.簡(jiǎn)單情況下的ERD建模2.硬數(shù)據(jù)的ERD建模3.復(fù)雜情況下的ERD建模4.ERD與過程模型3.1 簡(jiǎn)單情況下的ERD建模n從描述信息中辨識(shí)實(shí)體 q可以重點(diǎn)關(guān)注描述信息中的名詞，看系統(tǒng)是否需要收集其相關(guān)的特征n確定實(shí)體的標(biāo)識(shí)符 n建立實(shí)體間關(guān)系q判斷各個(gè)關(guān)系的建立是否會(huì)產(chǎn)生新的關(guān)聯(lián)實(shí)體或者影響已有的實(shí)體特性 n添加詳細(xì)的描述信息 q實(shí)體的詳細(xì)屬性和關(guān)系的基數(shù)3.1 簡(jiǎn)單情況下的ERD建模示例n研討班在每個(gè)學(xué)年開始的時(shí)候開設(shè)，然后持續(xù)一個(gè)學(xué)年。n每個(gè)研討班針對(duì)一個(gè)或幾個(gè)研究方向。n每個(gè)研討班由一位或幾位教師主持。n在研討班開設(shè)之后，學(xué)生可以根據(jù)主持教師（的姓名）和研討班的方向來(lái)選擇和參加某個(gè)研討班。n所有的學(xué)生必須且只能參加一個(gè)研討班的學(xué)習(xí)。n研討班時(shí)常會(huì)開展活動(dòng)，由教師來(lái)決定活動(dòng)的時(shí)間、地點(diǎn)、主題和做報(bào)告的學(xué)生（的姓名）。n每次活動(dòng)時(shí)，由一位或多位同學(xué)圍繞活動(dòng)主題做學(xué)習(xí)報(bào)告，交流自己對(duì)新技術(shù)的學(xué)習(xí)心得。n每個(gè)學(xué)生一次活動(dòng)最多只能作一個(gè)報(bào)告，但每個(gè)學(xué)生至少會(huì)在一次活動(dòng)中做一個(gè)報(bào)告。n教師對(duì)每份活動(dòng)中的學(xué)生報(bào)告進(jìn)行一次點(diǎn)評(píng)和指導(dǎo)，提出建議和意見。3.1 簡(jiǎn)單情況下的ERD建模示例3.1 簡(jiǎn)單情況下的ERD建模示例3.1 簡(jiǎn)單情況下的ERD建模示例3.1 簡(jiǎn)單情況下的ERD建模示例3.2 硬數(shù)據(jù)的ERD建模n分析表單內(nèi)容，確定表單主題分析表單內(nèi)容，確定表單主題 q每個(gè)主題描述為一個(gè)獨(dú)立的數(shù)據(jù)實(shí)體 n建立主題之間的關(guān)系建立主題之間的關(guān)系 n圍繞主題組織表單的項(xiàng)目圍繞主題組織表單的項(xiàng)目 3.2 硬數(shù)據(jù)的ERD建模示例3.2 硬數(shù)據(jù)的ERD建模示例3.3 復(fù)雜情況下的ERD建模1.發(fā)現(xiàn)系統(tǒng)的概念域發(fā)現(xiàn)系統(tǒng)的概念域 q指那些在系統(tǒng)業(yè)務(wù)中非常重要的概念，如果沒有這個(gè)概念，組織就可能不會(huì)存在或者業(yè)務(wù)發(fā)生重大變化 q不能遺漏那些對(duì)業(yè)務(wù)有重大影響的概念，同時(shí)概念域的發(fā)現(xiàn)也不要太細(xì)節(jié) q每一個(gè)概念域都會(huì)以星型發(fā)散的方式擴(kuò)展為多個(gè)邏輯實(shí)體 3.3 復(fù)雜情況下的ERD建模2.建立對(duì)概念域的描述建立對(duì)概念域的描述 概念域同義詞定義和描述資源相關(guān)的程序功能待確定的問題3.3 復(fù)雜情況下的ERD建模3.展開概念域展開概念域 q簡(jiǎn)單情況下的ERD建模q或者進(jìn)一步細(xì)分子域4.合并概念域的局部數(shù)據(jù)模型合并概念域的局部數(shù)據(jù)模型q消除冗余和沖突 3.4 ERD與過程模型n功能/實(shí)體矩陣（Function/Entity Matrix）q可以幫助驗(yàn)證過程模型和數(shù)據(jù)模塊的正確性，發(fā)現(xiàn)其中的錯(cuò)誤、遺漏、冗余和不一致 功能/實(shí)體學(xué)生課程注冊(cè)修改課程信息RU注冊(cè)課程RRC取消課程注冊(cè)RRD本章小結(jié)n在結(jié)構(gòu)化分析當(dāng)中，數(shù)據(jù)建模是過程建模的有利補(bǔ)充。n數(shù)據(jù)建模也可能會(huì)單獨(dú)發(fā)生，起到主導(dǎo)需求分析的作用nERD是最為常用的數(shù)據(jù)模型，它擁有完備的語(yǔ)法和語(yǔ)義nERD的建立過程通常是復(fù)雜的，但是復(fù)雜情況可以分為簡(jiǎn)單情況進(jìn)而逐一治之