中科院需求工程 需求工程 (第六講)基于情景的方法

1、金芝中國(guó)科學(xué)院數(shù)學(xué)與系統(tǒng)科學(xué)研究院方法概述情景分析和驗(yàn)證情景表示一個(gè)基于情景的需求分析工具情景研究新進(jìn)展小結(jié) The outline or script of a film, with details of scenes or an imagined sequence of future events Oxford English Dictionary Scenarios are example “stories” of normal events and critical incidents that represent the types of situations with which

2、performers must work and use the system McGraw K., 1994重構(gòu)當(dāng)前系統(tǒng)蘊(yùn)涵的概念和理念在概念層定義想要的改變實(shí)現(xiàn)要改變概念構(gòu)成新的系統(tǒng)與此同時(shí)，考慮遺產(chǎn)系統(tǒng) 純模型方法的問(wèn)題 能肯定這個(gè)模型真的反映了對(duì)變化的理解嗎？ 基于情景的方法 提供一個(gè)現(xiàn)實(shí)的，處于模型和現(xiàn)實(shí)之間的中間層抽象，可以克服這個(gè)問(wèn)題 可能情景的數(shù)量遠(yuǎn)遠(yuǎn)多于給定系統(tǒng)的模型的數(shù)量，許多研究者認(rèn)識(shí)到需要一個(gè)目標(biāo)層次導(dǎo)出基于情景的處理 使用情景作為系統(tǒng)需求的表示，改善開(kāi)發(fā)者和用戶之間的溝通 發(fā)現(xiàn)用戶的需要 將系統(tǒng)的使用方式嵌入系統(tǒng)開(kāi)發(fā)過(guò)程中 系統(tǒng)地研究測(cè)定系統(tǒng)的行為（包括正常行為和異常

3、行為） 與UML的用例緊密相關(guān)Visions用戶行為系統(tǒng)事件序列問(wèn)題用戶行為系統(tǒng)上下文現(xiàn)實(shí)世界情景設(shè)計(jì)制品情景設(shè)計(jì)理念模型規(guī)格說(shuō)明故事板概念展示器原型創(chuàng)建和驗(yàn)證泛化創(chuàng)建示例反映，驗(yàn)證線索追蹤模擬需求需求 非形式的定義：完成系統(tǒng)預(yù)期任務(wù)的一個(gè)特定執(zhí)行實(shí)例所包含動(dòng)作和事件的序列 開(kāi)發(fā)情景的目的：模擬運(yùn)作過(guò)程 情景的內(nèi)容，關(guān)于： 可能的出現(xiàn) 與這些出現(xiàn)相關(guān)的假設(shè) 可能的機(jī)會(huì)和風(fēng)險(xiǎn) 行為的過(guò)程 描述性的（descriptive）情景通過(guò)使系統(tǒng)分析師和用戶共同遍歷某一流程而理解流程相關(guān)的操作、參與者以及觸發(fā)流程的事件等因素。描述性的情景有助于對(duì)流程執(zhí)行的方式、流程的參與者以及流程啟動(dòng)的方式和條件進(jìn)行分類

4、。 解釋性的（explanatory）情景確定系統(tǒng)要解決的問(wèn)題并分析這些問(wèn)題出現(xiàn)的基本原理。這類情景揭示為什么現(xiàn)實(shí)世界中會(huì)發(fā)生某些事件？是什么導(dǎo)致這些事件的發(fā)生？什么是這些事件的動(dòng)因？以及哪些是經(jīng)常發(fā)生的和需要進(jìn)行處理的事件？解釋性情景的描述要開(kāi)發(fā)的系統(tǒng)所要求具有的功能。 探索性情景（exploratory）用于將需求與解決方案相關(guān)聯(lián)，對(duì)存在多種滿足系統(tǒng)需求的方案時(shí)非常有用，主要用于考查和評(píng)估這些方案，以得出其中最正確的方案。 實(shí)例情景包含帶實(shí)際參數(shù)值的特定名稱或事件。這類情景描述特定應(yīng)用實(shí)例，作為討論需求的基礎(chǔ)，如：發(fā)生了什么，為什么發(fā)生以及如何發(fā)生的。 類型情景不定義單個(gè)情景實(shí)例而是定義情

5、景實(shí)例的類型。因此類型情景不會(huì)涉及參與者王曉紅而只會(huì)涉及到顧客。類型情景的每一次執(zhí)行都是一個(gè)實(shí)例情景。 混合型情景中有些情景在實(shí)例級(jí)有些在類型級(jí)。 現(xiàn)實(shí)世界情景：現(xiàn)實(shí)世界事件發(fā)生序列，表示為敘事性文本、影象等，完全非形式表示 設(shè)計(jì)世界情景：想象中的目標(biāo)系統(tǒng)相關(guān)的事件序列，表示為設(shè)計(jì)的故事、動(dòng)畫(huà)型的動(dòng)作序列，可能需要是結(jié)構(gòu)化表示，如表格和情景文本等，或形式化表示 模型情景：按照模型的語(yǔ)法語(yǔ)義要求的事件序列，采用形式化表示，如基于正則表達(dá)式或自動(dòng)機(jī)等 將需求陳述和推理建立在具有一定細(xì)節(jié)的實(shí)例上，利于需求抽取 關(guān)注現(xiàn)實(shí)世界，解決具體的現(xiàn)實(shí)問(wèn)題中的困難。質(zhì)問(wèn)抽象模型難，判斷具體例子中的問(wèn)題容易 情景可

6、以作為測(cè)試案例測(cè)試規(guī)格說(shuō)明和設(shè)計(jì)模型 從情景中泛化出抽象模型的過(guò)程不好理解（但結(jié)合情景的抽象模型上的推理卻幫助理解） 情景可能會(huì)導(dǎo)致對(duì)頻繁出現(xiàn)的事件的過(guò)度關(guān)注，對(duì)出現(xiàn)不夠頻繁的事件的忽略（必須保證情景的覆蓋面） 情景越多越好，但過(guò)多的情景增加開(kāi)發(fā)的代價(jià)（情景集合的完整性和恰當(dāng)性） 情景主要集中在功能性需求上 目標(biāo)和關(guān)鍵成功因素 物理上下文和邏輯上下文 組成情景的主要事件和活動(dòng) 涉及的執(zhí)行者和其他參與者 要使用的信息和資源 要考慮的約束和要使用規(guī)則 需要作決策的點(diǎn)、要考慮的約束、要應(yīng)用的規(guī)則 性能問(wèn)題和提高的機(jī)會(huì) 目標(biāo)和關(guān)鍵成功因素 物理上下文和邏輯上下文 組成情景的主要事件和活動(dòng) 涉及的執(zhí)行者

7、和其他參與者 要使用的信息和資源 要考慮的約束和要使用規(guī)則 需要作決策的點(diǎn)、要考慮的約束、要應(yīng)用的規(guī)則 性能問(wèn)題和提高的機(jī)會(huì) 情景：用于描述一個(gè)存在系統(tǒng)以及它的環(huán)境的事實(shí)，包括主體主體(Agents)的行為的行為和進(jìn)行系統(tǒng)需求發(fā)現(xiàn)和驗(yàn)證的足夠的上下文信息上下文信息 很多情況下，作為UML用例圖的擴(kuò)展和補(bǔ)充 情景是系統(tǒng)使用的實(shí)例，常用于作為測(cè)試數(shù)據(jù)，和通過(guò)研究事件之間的關(guān)系來(lái)驗(yàn)證需求使用情景用戶1.目標(biāo)分析情景腳本5.社會(huì)影響分析6.涉眾分析4.輸出需求分析3.刻畫(huà)系統(tǒng)輸出2.輸入事件分析情景結(jié)構(gòu)模型需求規(guī)格說(shuō)明需求規(guī)格說(shuō)明目標(biāo),目的目標(biāo)列表系統(tǒng)模型輸入過(guò)程需求問(wèn)題實(shí)例用戶,環(huán)境事件初始系統(tǒng)模型

8、系統(tǒng)輸出類型信息需求Agent目標(biāo)分析用戶目標(biāo)，檢查是否需要系統(tǒng)功能的支持得出系統(tǒng)目標(biāo)，并引出系統(tǒng)功能需求識(shí)別系統(tǒng)和用戶以及環(huán)境的交互分析交互和所需求的功能，得出對(duì)輸入事件響應(yīng)方式根據(jù)輸入事件和系統(tǒng)目標(biāo)，得出系統(tǒng)的輸出事件分析系統(tǒng)輸出的用戶接受度，以及系統(tǒng)輸出事件的影響分析系統(tǒng)輸出是否對(duì)用戶任務(wù)提供必要的支持，并且沒(méi)有帶來(lái)不希望的結(jié)果進(jìn)行涉眾性能價(jià)格比用于評(píng)估系統(tǒng)輸出的影響，以及技術(shù)和社會(huì)系統(tǒng)的偶合對(duì)象活動(dòng)資源狀態(tài)事件Agents結(jié)構(gòu)對(duì)象目標(biāo)被改變描述改變觸發(fā)貢獻(xiàn)提供上下文負(fù)責(zé)具有實(shí)現(xiàn)空間信息和物理環(huán)境事實(shí)計(jì)算機(jī)輔助救護(hù)車分派系統(tǒng)功能救護(hù)車隊(duì)自動(dòng)車輛定位系統(tǒng)病人醫(yī)院控制中心公眾分派管理資源管理

9、資源標(biāo)識(shí)資源動(dòng)用呼叫處理倫敦道路空間道路事故救護(hù)車公眾車隊(duì)成員路徑規(guī)劃導(dǎo)航和駕駛病人處理到達(dá)事故現(xiàn)場(chǎng)穩(wěn)定病人將病人送達(dá)醫(yī)院路由知識(shí)處理的內(nèi)容支持實(shí)現(xiàn)執(zhí)行或涉及在其中進(jìn)行對(duì)象活動(dòng)資源目標(biāo)Agents結(jié)構(gòu)對(duì)象公眾控制助理資源裝配分派員無(wú)線電操作員社區(qū)站救護(hù)車隊(duì)員緊急呼救情況記錄發(fā)布指令事故定位消除重復(fù)創(chuàng)建消息發(fā)布指令駛向事故地點(diǎn)填寫(xiě)表格裝配資源情況報(bào)告情況報(bào)告 目標(biāo)分析啟發(fā)式 用戶目標(biāo)需要計(jì)算機(jī)支持嗎？如果是，在需求規(guī)格說(shuō)明中增加一條功能需求，否則增加非功能需求 目標(biāo)描述系統(tǒng)應(yīng)該實(shí)現(xiàn)的質(zhì)量或性能特性嗎？這些特性指定了可能不能直接實(shí)現(xiàn)的非功能性需求，非功能需求要和幫助實(shí)現(xiàn)它們的Agents和活動(dòng)相關(guān)

10、聯(lián) 如果目標(biāo)不要求計(jì)算機(jī)支持，它可以由手工過(guò)程達(dá)到嗎？這表明需要為社會(huì)系統(tǒng)活動(dòng)做一個(gè)操作過(guò)程手冊(cè) 目標(biāo)需要關(guān)于資源和職責(zé)的管理決策嗎？管理職責(zé)目標(biāo)需要與情景模型中的合適的Agent相連 情景目標(biāo)和它所關(guān)聯(lián)的活動(dòng)能夠完全自動(dòng)化嗎？如果能，則將這部分情景模型轉(zhuǎn)換為需求規(guī)格說(shuō)明，如果只需要部分自動(dòng)化，則需要模型的進(jìn)一步細(xì)化及其規(guī)格說(shuō)明 公眾：得到立即響應(yīng)，救護(hù)車快速到達(dá) 救護(hù)車隊(duì)：獲得事故和發(fā)生地點(diǎn)的準(zhǔn)確信息，以及完成這項(xiàng)任務(wù)的有用指令；盡快趕到事故地點(diǎn)；進(jìn)行輔助醫(yī)務(wù)處理；盡可能安全快捷地送達(dá)醫(yī)院 派遣員：確定事故地點(diǎn)和優(yōu)先級(jí)，計(jì)劃最近最合適的救護(hù)車的派遣；監(jiān)控呼叫進(jìn)展；獲得呼叫和救護(hù)車隊(duì)狀態(tài)的精確

11、信息 經(jīng)理：提供有效的服務(wù)并縮減代價(jià)；優(yōu)化救護(hù)車和車隊(duì)資源的使用 一些經(jīng)驗(yàn)教訓(xùn)： 許多目標(biāo)只能由人工活動(dòng)支持 規(guī)劃和調(diào)度是關(guān)鍵的活動(dòng)，它們依賴于幾個(gè)目標(biāo)，而且這些目標(biāo)分別出自不同的涉眾 出現(xiàn)目標(biāo)沖突情況 一開(kāi)始自動(dòng)調(diào)度系統(tǒng)是用于支持派遣任務(wù)的，但隨著分析的深入，這個(gè)支持顯得越來(lái)越不合適 雖然引入自動(dòng)系統(tǒng)是為了減少人力和提高資源的使用率，但這個(gè)系統(tǒng)對(duì)車隊(duì)的支持卻很少 通過(guò)跟蹤所有可能的輸入事件，檢查環(huán)境和系統(tǒng)的依賴關(guān)系 事件的來(lái)源： 環(huán)境中的Agents，通常是產(chǎn)生系統(tǒng)輸入的人 環(huán)境中引起事件出現(xiàn)的對(duì)象，比如，風(fēng)暴、動(dòng)物橫穿馬路、等等 對(duì)信息系統(tǒng)，大多數(shù)事件出自人 對(duì)實(shí)時(shí)系統(tǒng)，許多事件源于物理世

12、界或其它系統(tǒng) 對(duì)每個(gè)輸入事件，確定： 有系統(tǒng)功能來(lái)處理它嗎？如果沒(méi)有，則應(yīng)該加入新的功能性需求 該事件要求系統(tǒng)達(dá)到一個(gè)目標(biāo)狀態(tài)嗎？如果是的話，存在一個(gè)過(guò)程來(lái)完成行這個(gè)必要的變化嗎？ 該事件蘊(yùn)涵系統(tǒng)應(yīng)該維持一個(gè)目標(biāo)狀態(tài)嗎？如果是的話， 一旦系統(tǒng)離開(kāi)了這個(gè)狀態(tài)，系統(tǒng)能否解釋？ 系統(tǒng)能否采取補(bǔ)救行為回到想要的狀態(tài)？這些問(wèn)題蘊(yùn)涵監(jiān)控正常狀態(tài)和矯正偏差的功能性需求 事件的可靠性： 如果事件沒(méi)有出現(xiàn)怎么辦？系統(tǒng)能繼續(xù)運(yùn)行嗎？如果這個(gè)事件是必需的，系統(tǒng)要報(bào)告故障嗎？ 如果事件出現(xiàn)得太早或太晚怎么辦？系統(tǒng)對(duì)時(shí)間敏感嗎？來(lái)得早的事件可以緩存起來(lái)嗎？如果可以，緩存多少？來(lái)得晚的事件能容忍嗎？如果能，系統(tǒng)要停止其它

13、任務(wù)來(lái)響應(yīng)它，如果不能，系統(tǒng)要報(bào)錯(cuò)嗎？ 如果事件到達(dá)的次序不對(duì)怎么辦？系統(tǒng)是序列相關(guān)的嗎？如果是，需要緩存錯(cuò)誤排序的事件并重新排序嗎？ 如果事件重復(fù)出現(xiàn)怎么辦？系統(tǒng)能檢測(cè)出重復(fù)嗎？如果能，要消除多余的事件嗎？ 如果沒(méi)有預(yù)想到的事件發(fā)生了怎么辦？系統(tǒng)能夠處理未知輸入嗎？系統(tǒng)能夠解釋無(wú)關(guān)的事件并報(bào)告嗎？ 如果傳錯(cuò)了事件發(fā)生了怎么辦？系統(tǒng)能夠檢測(cè)出形式正確的事件的內(nèi)容被破壞了嗎？系統(tǒng)能夠請(qǐng)求事件發(fā)送者重發(fā)嗎？ 主要的三類事件蘊(yùn)涵不同的系統(tǒng)響應(yīng)： 可以驗(yàn)證發(fā)生次序和時(shí)間的已知事件：系統(tǒng)需要對(duì)照事件歷史檢測(cè)事件次序，并采取錯(cuò)誤矯正行為 可以在任何時(shí)候發(fā)生的已知事件：系統(tǒng)需要檢查事件發(fā)生的可能性，并提供回

14、滾操作幫助矯正用戶錯(cuò)誤，或者事件不正常出現(xiàn)時(shí)提示警告消息 未知事件：系統(tǒng)應(yīng)該繼續(xù)正確地運(yùn)行，需要例外捕獲過(guò)程，或者記錄機(jī)制，使研究人員可以研究例外事件。 進(jìn)一步的分析： 事件的來(lái)源可以跟蹤到某個(gè)特定個(gè)體嗎？如果可以，這個(gè)個(gè)體是否被授權(quán)發(fā)送這個(gè)事件？這個(gè)需求蘊(yùn)涵識(shí)別消息來(lái)源和個(gè)體口令保護(hù)的日志。在網(wǎng)絡(luò)環(huán)境下，事件的來(lái)源難以檢測(cè)到，這個(gè)要求隱含了對(duì)授權(quán)協(xié)議的需求。 其它安全的考慮：事件消息可以被其他人看到嗎？如果事件必須保密，則需要加密 倫敦救護(hù)車問(wèn)題 呼叫重復(fù)：引出識(shí)別呼叫者、事故地點(diǎn)和情況的需求，以消除重復(fù) 不同結(jié)果的事件對(duì)資源的需求不同：引出分析事故結(jié)果的需求 情景腳本中的兩個(gè)報(bào)告事件是對(duì)報(bào)

15、告事件的簡(jiǎn)化，因?yàn)閳?bào)告事件沒(méi)發(fā)生意味著可能的失效，引出對(duì)失效處理的需求 派遣員的指令是關(guān)鍵事件，準(zhǔn)確的信息更是關(guān)鍵 系統(tǒng)輸出的形式 消息顯示 對(duì)話框 語(yǔ)音合成 需求說(shuō)明形式： 列表 屏幕布局圖 故事板 原型界面 五種輸出事件類型 直接命令：要求人類采取行動(dòng)的輸出信息 間接命令：可以是警告消息或者信息顯示，它們隱含人類應(yīng)該采取行動(dòng) 輸入請(qǐng)求：提示系統(tǒng)需要用戶的輸入 信息顯示：僅僅描述信息，并不隱含需要立即的響應(yīng) 虛擬交互：模擬顯示，虛擬世界 任務(wù)：交叉檢索情景和需求規(guī)格說(shuō)明，保證輸出在需要的時(shí)候被產(chǎn)生 提示問(wèn)題：如果在情景腳本中，一個(gè)用戶在某個(gè)時(shí)間點(diǎn)需要某個(gè)信息，存在系統(tǒng)功能提供這個(gè)信息嗎？ 核

16、對(duì)表 針對(duì)需求規(guī)格說(shuō)明，對(duì)每個(gè)產(chǎn)生輸出的組件，情景中存在相應(yīng)的對(duì)該輸出信息的用戶需求嗎？ 在情景某個(gè)步驟上用戶需要的信息，該信息在它需要的時(shí)候能產(chǎn)生嗎？系統(tǒng)輸出和用戶任務(wù)的偶合依賴于應(yīng)用的類型，安全系統(tǒng)中要求精確的同步 用戶需要這個(gè)信息是為了支持決策嗎？指出輸出需求，即系統(tǒng)應(yīng)該提供信息幫助用戶作決策，或者提供執(zhí)行任務(wù)的指令 在情景中用戶的目的是尋找信息嗎？指出信息檢索需求 進(jìn)一步的分析（適合性，這是用戶想要的嗎？） 系統(tǒng)輸出的信息內(nèi)容對(duì)用戶任務(wù)或目標(biāo)來(lái)說(shuō)合適嗎？ 進(jìn)一步的分析（安全性） 誰(shuí)應(yīng)該得到這個(gè)輸出信息？ 收到信息的人不對(duì)怎么辦？需要加密功能 輸出丟失了怎么辦？需要登記消息日志、消息重發(fā)

17、的功能 輸出到的太早或太晚怎么辦？需要時(shí)效控制功能 輸出到達(dá)的次序不對(duì)怎么辦？需要保證輸出順序的功能如果輸出信息不允許流傳，需要跟蹤輸出目的地，獲得身份認(rèn)證等的功能，以保證到達(dá)正確的目的地，防止非法訪問(wèn) 倫敦救護(hù)車問(wèn)題 直接輸出： 直接命令：派遣員到救護(hù)車隊(duì)的命令 信息顯示：事故的位置和狀態(tài)，救護(hù)車行駛的情況，車隊(duì)和呼叫的分配關(guān)系 倫敦救護(hù)車問(wèn)題 系統(tǒng)輸出的使用： 車隊(duì)需要交通擁堵和道路狀況信息（未提供，因?yàn)檐囮?duì)和系統(tǒng)沒(méi)有直接的交互） 派遣員交通擁堵和道路狀況信息，以支持其進(jìn)行正確的決策 派遣指令傳送的正確性，要求車隊(duì)身份認(rèn)證 指令丟失導(dǎo)致呼叫無(wú)響應(yīng)，重復(fù)指令會(huì)導(dǎo)致重復(fù)派遣，指令次序錯(cuò)誤會(huì)引起

18、車隊(duì)混亂，要求指令通訊的正確無(wú)誤 不正確的指令導(dǎo)致系統(tǒng)混亂，要求交叉檢查指令的準(zhǔn)確性和正確性 困難的任務(wù)，因?yàn)?不知道準(zhǔn)確的社會(huì)理論，來(lái)預(yù)計(jì)人類用來(lái)應(yīng)對(duì)計(jì)算機(jī)系統(tǒng)的行為 缺少足夠的特定社會(huì)系統(tǒng)的知識(shí)來(lái)做這個(gè)預(yù)計(jì) 缺少穩(wěn)定的社會(huì)環(huán)境，使得在系統(tǒng)被夠建出來(lái)后這個(gè)預(yù)測(cè)仍然有效 一些可能的考慮點(diǎn)： 評(píng)估社會(huì)系統(tǒng)和技術(shù)系統(tǒng)的偶合度 系統(tǒng)輸出記數(shù) 緊偶合加大了二者的依賴程度，導(dǎo)致系統(tǒng)容易出錯(cuò) 設(shè)計(jì)一些自治的子系統(tǒng)來(lái)減少偶合度 社會(huì)系統(tǒng)的文化影響對(duì)偶合度的容忍程度，層次式組織結(jié)構(gòu)容易容忍緊偶合，網(wǎng)絡(luò)化組織適合于松偶合 一些可能的考慮點(diǎn)： 情景結(jié)構(gòu)模型的不同細(xì)化，產(chǎn)生不同的系統(tǒng)邊界，導(dǎo)致不同的（人和機(jī)器之間）

19、任務(wù)分配 過(guò)多的自動(dòng)化會(huì)削弱人的職責(zé) 過(guò)多的自動(dòng)化會(huì)削弱人對(duì)整個(gè)系統(tǒng)的意識(shí)，導(dǎo)致人對(duì)意外處理的能力下降 強(qiáng)迫人做他不想做的任務(wù)的這種自動(dòng)化，增加人的抵觸情緒 強(qiáng)加給人很多新任務(wù)的緊偶合自動(dòng)化，用不自然的方式限制了人類的活動(dòng)，也會(huì)增加人的抵觸情緒 人與自動(dòng)系統(tǒng)的偶合應(yīng)該對(duì)用戶的知識(shí)和技能敏感 自動(dòng)系統(tǒng)的引入不能改變?nèi)伺c人之間的職責(zé)關(guān)系和權(quán)利關(guān)系 在系統(tǒng)邊界確定之后，進(jìn)行輸出結(jié)構(gòu)影響分析，考慮系統(tǒng)輸出是否能實(shí)現(xiàn)用戶目標(biāo)，授權(quán)關(guān)系是否清楚，是否沒(méi)有沖突。 信息輸出的影響分析： 信息輸出給每個(gè)Agent會(huì)增加他的權(quán)利嗎？會(huì)削弱其他Agent的權(quán)利嗎？ 輸出的信息會(huì)被惡意使用嗎？ 情景結(jié)構(gòu)模型用于影響分

20、析，第一步評(píng)估命令影響的啟發(fā)式： 系統(tǒng)的這個(gè)輸出觸發(fā)了人類Agent負(fù)責(zé)的一個(gè)活動(dòng)嗎？如果是這就是一個(gè)直接命令 系統(tǒng)的這個(gè)輸出對(duì)人類Agent的一個(gè)決策活動(dòng)是必須的嗎？如果是這就是一個(gè)間接命令 系統(tǒng)的這個(gè)輸出對(duì)人類Agent完成一個(gè)活動(dòng)有幫助嗎？如果是這就是一個(gè)間接依賴 情景結(jié)構(gòu)模型用于影響分析，第二步評(píng)估目標(biāo)、職責(zé)、作用和授權(quán)等的啟發(fā)式。對(duì)每個(gè)輸出命令，評(píng)估將涉及的Agents： 檢查Agent的特性確定他們是否具備必要的技能或知識(shí)來(lái)執(zhí)行這個(gè)任務(wù)，如果不是，隱含需要人員選拔或培訓(xùn) 檢查Agent的作用和任務(wù)，如果這個(gè)命令給的人錯(cuò)了，隱含需要改變社會(huì)系統(tǒng) 檢查Agent是否能夠按時(shí)并按合適的方

21、式來(lái)響應(yīng)這個(gè)命令，研究制定決策或者執(zhí)行任務(wù)的時(shí)間要求 情景結(jié)構(gòu)模型用于影響分析，第三步檢查用戶是否可能接受這個(gè)命令： 命令會(huì)導(dǎo)致組織職責(zé)分配的無(wú)序嗎？要求一個(gè)Agent接受一個(gè)超出職責(zé)范圍的決定 命令破壞了用戶的授權(quán)嗎？系統(tǒng)需要用戶在錯(cuò)誤的時(shí)間接受一個(gè)決定 命令改變了人類Agents之間的權(quán)利關(guān)系嗎？命令削弱了一個(gè)Agent的權(quán)利而增加了另一個(gè)Agent的權(quán)利 對(duì)每類涉眾： 新系統(tǒng)降低了他們工作的技能嗎？（過(guò)度自動(dòng)化） 新系統(tǒng)威脅到他們工作的保密性嗎？ 他們的職責(zé)將被新系統(tǒng)削弱嗎？（自動(dòng)化或者職責(zé)重新分配） 系統(tǒng)影響工作積極性嗎？（過(guò)度偶合、太不靈活、剝奪自主性、沒(méi)有提供足夠的信息、等）公眾車

22、隊(duì)派遣員醫(yī)院管理者報(bào)告狀態(tài)緊急呼叫呼叫定位，消除重復(fù)，規(guī)劃資源指令車隊(duì)到達(dá)事故現(xiàn)場(chǎng)穩(wěn)定病人報(bào)告運(yùn)送病人報(bào)告政策規(guī)劃響應(yīng)策略涉眾工作保密性職責(zé)控制工作量經(jīng)理+監(jiān)督員+派遣員-+車隊(duì)- 基于時(shí)間區(qū)間的情景表示 嚴(yán)格順序：ev(endA)ev(startA) 部分順序： (ev(startA)ev(endB) and (ev(endA)ev(endB) 包含：(ev(startA)ev(endB) 并發(fā)： 交替：(ev(startA) occurs) or (ev(startB) occurs) 并行：(ev(startA)=ev(startB) and (ev(endA) = ev(endB) 同

23、時(shí)開(kāi)始：(ev(startA)=ev(startB) and (ev(endA) not= ev(endB) 同時(shí)結(jié)束：(ev(startA) not= ev(startB) and (ev(endA) = ev(endB) 情景用來(lái)早期原型化抽取需求 提供集成的技術(shù)，讓用戶積極參與，得到用戶的有效反饋 利用情景作為背景討論設(shè)計(jì)方案、引出新的需求故事板展現(xiàn)和想象場(chǎng)景需求細(xì)化和驗(yàn)證原型和需求驗(yàn)證用戶需求交互設(shè)計(jì)初始需求捕獲高層想象/需求經(jīng)理，用戶項(xiàng)目啟動(dòng)情景用戶任務(wù)實(shí)物模型故事板最終開(kāi)發(fā)概念展示器情景設(shè)計(jì)理念測(cè)試任務(wù)情景需求初始設(shè)計(jì)驗(yàn)證需求求精設(shè)計(jì)傳統(tǒng)的面談法等信息采集技術(shù)為要構(gòu)造的系統(tǒng)創(chuàng)建早期

24、的想象,通過(guò)故事板向用戶解釋并獲取反饋通過(guò)概念展示器和早期原型向用戶表現(xiàn)更細(xì)的設(shè)計(jì),進(jìn)行情景驅(qū)動(dòng)的,半交互式的證明開(kāi)發(fā)更全面的功能原型,并繼續(xù)求精需求,直到原型被所有用戶接受 本船是一艘現(xiàn)代運(yùn)輸船（3萬(wàn)噸），有36個(gè)船員和5個(gè)管理人員（國(guó)際化），上午10點(diǎn)離開(kāi)南開(kāi)普頓，向方向開(kāi)進(jìn)，現(xiàn)在位置在，現(xiàn)在的氣象條件好，能見(jiàn)度15英里，西北風(fēng)，風(fēng)力3級(jí)。 下午3:10pm，一個(gè)船員報(bào)告發(fā)現(xiàn)在2號(hào)船艙發(fā)現(xiàn)煙霧，發(fā)出火警信號(hào) 研究發(fā)生火警的位置，如果必要向船員發(fā)出疏散命令 如果有，啟動(dòng)自動(dòng)火警撲滅系統(tǒng) 廣播命令，讓船員開(kāi)始救火 分配初級(jí)管理人員領(lǐng)導(dǎo)救火隊(duì) 檢查船貨，看是否有危險(xiǎn)品靠近火警點(diǎn) 計(jì)劃救火策略，考

25、慮危險(xiǎn)品和其它災(zāi)害 發(fā)布救火指令，監(jiān)控救火過(guò)程，直到火警消除 情景是事件的序列 從用例的角度看： 是穿越用例的一條可能的路徑 情景是從用例中導(dǎo)出的行為/活動(dòng)的序列 每個(gè)用例可能導(dǎo)出多個(gè)情景 對(duì)由多個(gè)情景組成的集合進(jìn)行推理，需要適當(dāng)?shù)谋磉_(dá)手段和推理機(jī)制 基本假設(shè)： 區(qū)間是表示時(shí)間的基本單位 時(shí)間是度量客觀事件發(fā)生的先后和延續(xù)性的一種標(biāo)準(zhǔn) 客觀事件的發(fā)生總是有一個(gè)過(guò)程 區(qū)間長(zhǎng)度一般不為零 有兩個(gè)時(shí)間點(diǎn)：起點(diǎn)t(A)-和終點(diǎn)t(A)+ 基本假設(shè)：時(shí)間區(qū)間是半開(kāi)半閉的 假設(shè)A、B表示兩個(gè)時(shí)間區(qū)間 A在B之前：AB，具體特征：t(A)+ t(B)- A等于B：A=B，具體特征：t(A)- = t(B)-

26、， t(A)+ = t(B)+ A遇上B：A m B，具體特征：t(A)+ = t(B)- A交叉B：A o B，具體特征：t(A)- t(B)- t(A)+ t(B)+ A在B中：A d B，具體特征：t(B)- t(A)- t(A)+ t(B)+ A開(kāi)始B：A b B，具體特征：t(A)- = t(B)- t(A)+ t(B)+ A結(jié)束B(niǎo)：A e B，具體特征：t(B)- t(A)- t(A)+ = t(B)+ 買賣用例中的事件 事件A：賣方拿起電話 事件B：買方請(qǐng)求報(bào)價(jià) 事件C：交易系統(tǒng)顯示價(jià)格 事件D：賣方拒絕買賣 事件E：賣方檢索價(jià)格信息 事件F： 事件之間的時(shí)間區(qū)間關(guān)系 A在B之前

27、：t(A)+ t(B)- B在C之前：t(B)+ t(C)- B在D之前：t(B)+ t(D)- B交叉E： t(B)- t(E)- t(B)+ t(E)+ E交叉C： t(E)- t(C)- t(E)+ t(C)+ 根據(jù)時(shí)間關(guān)系約束產(chǎn)生可能的情景 情景一：t(A)- t(A)+ t(B)- t(E)- t(B)+ t(E)+ t(C)- t(C)+ 情景二：t(A)- t(A)+ t(B)- t(E)- t(B)+ t(C)- t(E)+ t(C)+ 情景三：t(A)- t(A)+ t(B)- t(B)+ t(D)- t(D)+ 情景和類模型的一致性檢測(cè) 將情景和類圖等結(jié)構(gòu)顯式地表示出來(lái)，并

28、對(duì)所有的圖元進(jìn)行命名 定義一些檢測(cè)的規(guī)則，包括 可形式檢測(cè)的規(guī)則，如： 名一致性規(guī)則 語(yǔ)法正確性規(guī)則 引用正確性規(guī)則 人工檢測(cè)的規(guī)則，如： 重疊最小化 避免缺少信息 內(nèi)容的對(duì)應(yīng)性 信息流的充分性 關(guān)于領(lǐng)域特性的規(guī)則 誤用用例，misuse case 濫用用例，abuse case 一個(gè)可以被任何人或?qū)嶓w為了破壞系統(tǒng)的進(jìn)行的行為序列 表示系統(tǒng)應(yīng)該避免的應(yīng)用場(chǎng)景 誤用戶，misuser 觸發(fā)誤用用例的參與者，有意的或無(wú)意的 誤用用例圖：關(guān)系 一般用例中的關(guān)系： Include Extend Generalize Association 新的關(guān)系 Mitigate：一個(gè)用例能夠減少一個(gè)誤用用例成功的

29、機(jī)會(huì) Threaten：一個(gè)誤用用例能夠?qū)σ粋€(gè)用例產(chǎn)生威脅，比如利用一個(gè)用例，或者阻止一個(gè)用例，來(lái)達(dá)到它的目的 從誤用用例中識(shí)別安全需求 識(shí)別系統(tǒng)中的關(guān)鍵資產(chǎn) 對(duì)每個(gè)關(guān)鍵資產(chǎn)，定義安全目標(biāo) 通過(guò)識(shí)別想要危害這個(gè)系統(tǒng)的系統(tǒng)參與者，來(lái)識(shí)別每個(gè)安全目標(biāo)的威脅 采用風(fēng)險(xiǎn)技術(shù)，識(shí)別和分析威脅的風(fēng)險(xiǎn) 對(duì)這些風(fēng)險(xiǎn)定義安全需求 從誤用用例中識(shí)別安全需求 識(shí)別系統(tǒng)中的關(guān)鍵資產(chǎn) 對(duì)每個(gè)關(guān)鍵資產(chǎn)，定義安全目標(biāo) 通過(guò)識(shí)別想要危害這個(gè)系統(tǒng)的系統(tǒng)參與者，來(lái)識(shí)別每個(gè)安全目標(biāo)的威脅 采用風(fēng)險(xiǎn)技術(shù)，識(shí)別和分析威脅的風(fēng)險(xiǎn) 對(duì)這些風(fēng)險(xiǎn)定義安全需求 一種表示法，圖示出與候選系統(tǒng)組件相關(guān)的場(chǎng)景路徑 基于情景的軟件工程技術(shù)，描述一個(gè)或多

30、個(gè)用例的職責(zé)之間的因果關(guān)系 用類似路徑圖的形式顯示有關(guān)的用例UCM例例: 通勤通勤鎖門鎖門XX來(lái)回往返來(lái)回往返X乘電梯乘電梯準(zhǔn)備準(zhǔn)備好離好離開(kāi)家開(kāi)家在辦在辦公室公室家家交通工具交通工具電梯電梯Responsibility PointBasic Path(from circle to bar)Component(generic) 橋接需求和設(shè)計(jì)之間的建模鴻溝橋接需求和設(shè)計(jì)之間的建模鴻溝 用顯式可視化的方式連接行為和結(jié)構(gòu) 為高層設(shè)計(jì)層的體系結(jié)構(gòu)決策提供行為框架 一旦體系結(jié)構(gòu)出來(lái)后，刻畫(huà)體系結(jié)構(gòu)層的行為 在一個(gè)圖中表達(dá)了很多方面的信息 集成了一個(gè)情景，便宜推斷出潛在的不希望出現(xiàn)的情景交互 提供為動(dòng)態(tài)

31、系統(tǒng)建模的能力，這種系統(tǒng)可能在運(yùn)行時(shí)改變情景和結(jié)構(gòu) 電子商務(wù)應(yīng)用 遠(yuǎn)程通訊系統(tǒng) 簡(jiǎn)單、直觀、易學(xué) 邊設(shè)計(jì)邊文檔化 不熟悉領(lǐng)域的開(kāi)發(fā)人員學(xué)習(xí)領(lǐng)域知識(shí)的有效工具 經(jīng)過(guò)直接的變換就可以轉(zhuǎn)化為消息序列圖、系統(tǒng)性能模型和測(cè)試用例UCM Example: CommutingreadytoleavehomeincubiclehometransportelevatorsecurehomeXXcommuteXtakeelevatorsecurehomecommutetakeelevatorDynamic Stub(selection policy)Static StubstayhomeUCM Example:

32、Commute - Car (Plug-in)transportXdrive carUCM Example: Commute - Bus (Plug-in)personreadDilbertXXtake 182AND ForkOR JoinOR ForkAND JointransportXtake 97Xtake 95-Generic UCM ExamplestartendDynamic Responsibilities and Dynamic Componentsslot Apool Apool B+createcreateslot Bcopydestroy-destroy+move out

33、move intomove intoGeneric UCM Examplestartendslot Apool Apool B+createcreatemove outslot Bmove intocopymove intodestroy-destroy+Slot(component)Pool(component) 需求捕獲 體系結(jié)構(gòu)評(píng)估 驗(yàn)證和特征交互檢測(cè) 到設(shè)計(jì)和測(cè)試的轉(zhuǎn)換UserElevator Control Systeminelevatorabovebelowat requestedfloorArrival Sensorapproachingfloordoorclosing-dela

34、yadd to listelseno requestsstationarymovingnot requesteddoor closemotor upmotor downmovingdecide ondirectionmotorstoprequesteddooropenSelect Destinationremovefrom listmore requestsThe elevator control system case study is adapted from Hassan Gomaas Designing Concurrent, Distributed, And Real-Time Ap

35、plications with UML (p459-462), copyright Hassan Gomaa 2001, published by Addison Wesley. Used with permission.需求捕獲UserArrival SensorService PersonnelSchedulerElevatorinelevatorabovebelowdecide on directionelsedoor closemotorupmotordownmovingat floorupdownselectelevatorapproachingfloornot requestedm

36、otorstoprequesteddoor openat requestedfloorstationary-memoryswitch ondoorclosing-delayadd toliston listalreadyon listremove from listArch. Alternative (I)體系結(jié)構(gòu)評(píng)估UserService PersonnelElevatorSchedulerStatus&PlanStatus&PlanElev. ControlElev. Mgrinelevatorabovebelowdecide ondirectionelsedoorclosemotorupmotordownmovingat floorupdownselectelevatorArrival Sensorapproachingfloornot requestedmotorstopdoor openstationary-memoryswitch ondoorclosing-delayadd tolistalreadyon liston listrequestedremovefrom listat requestedfloorArch. Alternative (II)體