【正文】 s additional requests: after creation of the order Supply Customer Data Order Produck Arrange Payment Request Catalog salesperson 例： USE CASE 關(guān)系 Actor 關(guān)系 Supervisor Establish Credit 1 * 6） 、 USE CASE圖 USE CASE圖給出了操作者和 USE CASE以及它們之間的關(guān)系 。 ? 包含： USE CASE A到 USE CASE B的一個包含 ， 指出 A的一個實例將包含 B說明的行為 ， 即這一行為將包含在A定義的那部分中 。 關(guān)聯(lián)是操作者和 USE CASE之間的唯一關(guān)系 。 5） 、 關(guān)系 在 USE CASE之間 ， 或在操作者與 USE CASE之間 ， 存在一些標(biāo)準(zhǔn)的關(guān)系： ? 關(guān)聯(lián)：參與關(guān)系 ， 即操作者參與一個 USE CASE。 ? 場景法（ Scenario Generation） – 讓用戶窮舉他們現(xiàn)有的所有的數(shù)據(jù)處理實踐以及任何計劃中將要新增加的數(shù)據(jù)類型與處理過程。 ? 原型法（ Prototyping） – 從用戶處取得一組基本的 USE CASE產(chǎn)品要求之后， 立即建造 USE CASE產(chǎn)品的原型（這個原型可以是實際可運(yùn)行的軟件（外殼），或是一個用描述來表達(dá)的產(chǎn)品），然后讓用戶去模擬使用這個原型，提出修改的意見。 通常，一個操作者被表示為： 4）、 USE CASE獲取 ? 仿真法（ Simulation） – 掌握用戶的所有輸入與輸出的數(shù)據(jù)種類，通過仿真的方法，找出它們之間的對應(yīng)關(guān)系，與及相應(yīng)的數(shù)據(jù)處理過程。 3）、 操作者語義與表示 一個操作者定義了一組高內(nèi)聚的角色，當(dāng)用戶與該 實體交互時，用戶可以扮演這一角色。 為了表明 USE CASE所包含的具體內(nèi)容，還應(yīng)給出它 的正文描述。 ? 表示與描述 USE CASE通常被表示為： USE CASE包含一組操作和屬性，這些操作和屬性 規(guī)約了該 USE CASE的實例所執(zhí)行的那個動作序列。 通過這一約定 ， 描述了該語義實體在不同條件下的行為對參與者一個要求的響應(yīng) ， 以實現(xiàn)某一目的 。 2）、語義與表示 ? USE CASE語義 一個 USE CASE是系統(tǒng)或其它語義實體 （ 例如子系統(tǒng)或一個類 ） 所提供的一塊 (unit)高內(nèi)聚的功能 ， 顯露該系統(tǒng)和一個或多個外部的交互者 （ 稱為操作者 ） 交替出現(xiàn)的消息序列， 以及該系統(tǒng)所執(zhí)行的動作 。 ? Use Case不但有助于幫助分析員理清思路；驗證用戶需求。 ? Use Case既然是對系統(tǒng)行為的動態(tài)描述，因此它是類、對象、操作的來源，是系統(tǒng)分析和設(shè)計階段的輸入之一，是分析和設(shè)計，制定開發(fā)計劃，測試計劃，設(shè)計測試用例的依據(jù)之一。為此使用了一種用戶和開發(fā)人員都能理解方式描述系統(tǒng)功能和行為。 支持使用問題空間的術(shù)語，思考問題和編制文檔 允許采用多種可供選擇的設(shè)計方法 提供定義系統(tǒng)邊界的方法 5）需求獲取技術(shù)特征 由上可見，需求獲取技術(shù)特征： ? 劃分： 捕獲問題空間的“整體 /部分”關(guān)系 是降低問題復(fù)雜性的基本途徑之一 ? 投影 ：捕獲問題空間的多維“視圖” 是描述問題的基本手段之一 ??? 好的思維來源于 ： 嚴(yán)謹(jǐn)、邏輯和“活躍”的思考習(xí)慣。 4）需求的原則 分析問題和需求的能力取決于分析人員的 思維 和 經(jīng)驗 。 重要性之二 ?? 軟件需求 這種發(fā)生在軟件生命周期的初始階段 的錯誤是非常難于改正，并且是代價極高的。 重要性之一 ?? 軟件需求工程直接關(guān)系到 “ 成本、質(zhì)量和按時交付 ” 等問題 它們是項目成敗的關(guān)鍵因素。 其中，與產(chǎn)品需求有關(guān)的（ 1,2,4,和 6項）占了 %。 2)需求面臨的挑戰(zhàn) ? 問題空間理解 ? 人與人之間的通信 ? 需求的不斷變化 3）需求的重要性 StandishGroup對 350家公司的 8000個軟件項目作過一次調(diào)查 其中， 31%的項目的結(jié)局是被取消。 瀑布模型 演化模型 增量模型 螺旋模型 噴泉模型 ? ? ? －外征：軟件開發(fā)活動的組織 －內(nèi)涵：求解軟件的計算邏輯 分 析 編 碼 （ 1）瀑布模型 50年代末：二級模型 “做什么” “編程 實現(xiàn)” 需求分析 設(shè) 計 編 碼 測 試 運(yùn) 行 瀑布模型雛型 系統(tǒng)需求 軟件需求 需求分析 設(shè) 計 編 碼 測 試 運(yùn) 行 1970年， 將雛型進(jìn)一步精化 其中：每一階段具有以下特征： ?從上一階段接受工作對象，即輸入； ?對這一輸入實施本階段的工作 ? 給出本階段的結(jié)果作為輸出。 給出了軟件工程學(xué)科所研究的主要內(nèi)容 軟件工程的基本活動 1)、需求 定義問題，即建立系統(tǒng)模型 主要任務(wù)包括： 1〕 需求獲取 －需求定義 系統(tǒng)功能的一個正確的陳述 2〕 需求規(guī)約 ― －系統(tǒng)需求規(guī)格說明 主要成分：系統(tǒng)模型 系統(tǒng)功能的一個精確、系統(tǒng)的描述 3〕 需求驗證 2)、設(shè)計 在需求分析的基礎(chǔ)上，給出系統(tǒng)的軟件解決方案。 給出了軟件工程所涉及的工程要素 軟件工程是一門交叉性學(xué)科。它借鑒傳統(tǒng)工程的原則、方法，以提高質(zhì)量，降低成本為目的。細(xì)言之， …… 工程－ 將理論和所學(xué)的知識應(yīng)用于實踐的科學(xué)。軟件工程培訓(xùn)講義 （上） 軟件工程概念 軟件開發(fā)模型 系統(tǒng)建模技術(shù) 結(jié)構(gòu)化方法 系統(tǒng)建模技術(shù) 面向?qū)ο蠓椒? 軟件測試 軟件過程 ISO90003與 CMM簡介 軟件工具、平臺與環(huán)境 “ 建模 ” 在軟件開發(fā)中的 “ 定位 ” 應(yīng) 用 系 統(tǒng) 語 言 思維體系與方法 問題表達(dá)能力VB 、 VC 程序設(shè)計環(huán)境軟件體系結(jié)構(gòu)軟件框架設(shè)計模式 運(yùn)行平臺 開發(fā)平臺 建模（人與工具）網(wǎng)絡(luò) 異構(gòu)第一章、軟件工程及軟件工程框架 軟件－ 計算機(jī)系統(tǒng)中的程序及其文檔。程序是計算任務(wù)的處理對象和處理規(guī)則的描述；文檔是為了便于了解程序所需的闡明性資料。 軟件工程－ 應(yīng)用計算機(jī)科學(xué)、數(shù)學(xué)及管理科學(xué)等原理，開發(fā)軟件的工程。其中，計算機(jī)科學(xué)、數(shù)學(xué)用于構(gòu)造模型與算法，工程科學(xué)用于制定規(guī)范、設(shè)計范型、評估成本及確定權(quán)衡，管理科學(xué)用于用于計劃、資源、質(zhì)量、成本等管理。 軟件工程框架 工程目標(biāo) 正 可 合 確 用 算 確 支 工 設(shè) 實 程 需 認(rèn) 持 原 計 現(xiàn) 則 求 動 活采用合適的開發(fā)范型使用好的設(shè)計方法提供高質(zhì)量的工程支持實施有效的工程管理軟件工程可定義為三元組： ? 目標(biāo)，原則，活動 ? 給出了各要素之間的關(guān)系 1〕 總體設(shè)計 系統(tǒng)的軟件體系結(jié)構(gòu) C/S結(jié)構(gòu) 以數(shù)據(jù)庫為中心的結(jié)構(gòu) 管道結(jié)構(gòu) 面向?qū)ο蟮慕Y(jié)構(gòu) …… 2〕 詳細(xì)設(shè)計 針對總體設(shè)計結(jié)果，給出每一構(gòu)件的詳 細(xì)描述 3）、實現(xiàn) 選擇可用的構(gòu)件；或 以一種選定的語言，對每一構(gòu)件進(jìn)行編碼 4）、 確認(rèn) 貫穿軟件開發(fā)的整個過程 主要任務(wù)是：軟件測試 5）、 支持 完善性維護(hù) 糾錯性維護(hù) 第二章、軟件開發(fā)模型 軟件開發(fā)模型 軟件過程、活動、任務(wù)的結(jié)構(gòu)框架。 系統(tǒng)需求 軟件需求 需求分析 設(shè) 計 編 碼 測 試 運(yùn) 行 歸納邏輯： P Q P?Q 瀑布模型 ?活動如瀑布流水式的組織 ?規(guī)定每一活動的工作對象和輸出 ?評審、確認(rèn)和反饋 問題：無法通過開發(fā)活動 澄清本來不確切的軟件需求 ?維護(hù)、甚至返工的代價 需求 設(shè)計 編碼 測試 集成 需求 設(shè)計 編碼 測試 集成 開 發(fā) 反 饋 開 發(fā) 反 饋 ... 核 心 系 統(tǒng) 開 發(fā) 第 二 次 迭 代 （ 2）演化模型 ? 針對事先不能完整地定義需求 ? 針對用戶的核心需求 ,開發(fā)核心系統(tǒng) ? 根據(jù)用戶的反饋 ,實施活動的迭代 1 3 2 5 9 10 11 6 7 12 13 8 4 增量 1 ? 1,2,5,9 ? 增量 2 ? 3,6,7,4,10,11 ? 增量 3 ? 8,12,13 ? 管理 增量規(guī)約 增量設(shè)計 糾錯性分析 增量實現(xiàn) 增量 1 增量 2 增量 3 （ 3）增量模型 微軟 “ 同步 穩(wěn)定的產(chǎn)品開發(fā)模型 ” ? 將項目分為若干個里程碑階段 ? 定義穩(wěn)定、靈活的體系結(jié)構(gòu)，并為構(gòu)件 和子系統(tǒng)的開發(fā)提供統(tǒng)一的接口 ? 開發(fā)構(gòu)件，維持一個可發(fā)布的系統(tǒng)版本 可以準(zhǔn)確把握項目進(jìn)展情況 增強(qiáng)開發(fā)人員的信心和成就感 可以隨時根據(jù)市場情況及時作出調(diào)整 演化 維護(hù) 確認(rèn) 實現(xiàn) 設(shè)計 分析 噴泉模型 ? 特征：迭代 無縫 ? 與面向?qū)ο蠹夹g(shù) 的關(guān)系 第三章 系統(tǒng)建模技術(shù) 結(jié)構(gòu)化方法 （一）結(jié)構(gòu)化分析方法 要回答：如何定義問題？ 涉及： 如何獲得需求