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

1、金芝中國科學院數學與系統(tǒng)科學研究院方法概述情景分析和驗證情景表示一個基于情景的需求分析工具情景研究新進展小結 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重構當前系統(tǒng)蘊涵的概念和理念在概念層定義想要的改變實現(xiàn)要改變概念構成新的系統(tǒng)與此同時，考慮遺產系統(tǒng) 純模型方法的問題 能肯定這個模型真的反映了對變化的理解嗎？ 基于情景的方法 提供一個現(xiàn)實的，處于模型和現(xiàn)實之間的中間層抽象，可以克服這個問題 可能情景的數量遠遠多于給定系統(tǒng)的模型的數量，許多研究者認識到需要一個目標層次導出基于情景的處理 使用情景作為系統(tǒng)需求的表示，改善開發(fā)者和用戶之間的溝通 發(fā)現(xiàn)用戶的需要 將系統(tǒng)的使用方式嵌入系統(tǒng)開發(fā)過程中 系統(tǒng)地研究測定系統(tǒng)的行為（包括正常行為和異常

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22、隊派遣員醫(yī)院管理者報告狀態(tài)緊急呼叫呼叫定位，消除重復，規(guī)劃資源指令車隊到達事故現(xiàn)場穩(wěn)定病人報告運送病人報告政策規(guī)劃響應策略涉眾工作保密性職責控制工作量經理+監(jiān)督員+派遣員-+車隊- 基于時間區(qū)間的情景表示 嚴格順序：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、時開始：(ev(startA)=ev(startB) and (ev(endA) not= ev(endB) 同時結束：(ev(startA) not= ev(startB) and (ev(endA) = ev(endB) 情景用來早期原型化抽取需求 提供集成的技術，讓用戶積極參與，得到用戶的有效反饋 利用情景作為背景討論設計方案、引出新的需求故事板展現(xiàn)和想象場景需求細化和驗證原型和需求驗證用戶需求交互設計初始需求捕獲高層想象/需求經理，用戶項目啟動情景用戶任務實物模型故事板最終開發(fā)概念展示器情景設計理念測試任務情景需求初始設計驗證需求求精設計傳統(tǒng)的面談法等信息采集技術為要構造的系統(tǒng)創(chuàng)建早期

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

25、慮危險品和其它災害 發(fā)布救火指令，監(jiān)控救火過程，直到火警消除 情景是事件的序列 從用例的角度看： 是穿越用例的一條可能的路徑 情景是從用例中導出的行為/活動的序列 每個用例可能導出多個情景 對由多個情景組成的集合進行推理，需要適當的表達手段和推理機制 基本假設： 區(qū)間是表示時間的基本單位 時間是度量客觀事件發(fā)生的先后和延續(xù)性的一種標準 客觀事件的發(fā)生總是有一個過程 區(qū)間長度一般不為零 有兩個時間點：起點t(A)-和終點t(A)+ 基本假設：時間區(qū)間是半開半閉的 假設A、B表示兩個時間區(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開始B：A b B，具體特征：t(A)- = t(B)- t(A)+ t(B)+ A結束B：A e B，具體特征：t(B)- t(A)- t(A)+ = t(B)+ 買賣用例中的事件 事件A：賣方拿起電話 事件B：買方請求報價 事件C：交易系統(tǒng)顯示價格 事件D：賣方拒絕買賣 事件E：賣方檢索價格信息 事件F： 事件之間的時間區(qū)間關系 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)+ 根據時間關系約束產生可能的情景 情景一：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)+ 情景和類模型的一致性檢測 將情景和類圖等結構顯式地表示出來，并

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

29、機會 Threaten：一個誤用用例能夠對一個用例產生威脅，比如利用一個用例，或者阻止一個用例，來達到它的目的 從誤用用例中識別安全需求 識別系統(tǒng)中的關鍵資產 對每個關鍵資產，定義安全目標 通過識別想要危害這個系統(tǒng)的系統(tǒng)參與者，來識別每個安全目標的威脅 采用風險技術，識別和分析威脅的風險 對這些風險定義安全需求 從誤用用例中識別安全需求 識別系統(tǒng)中的關鍵資產 對每個關鍵資產，定義安全目標 通過識別想要危害這個系統(tǒng)的系統(tǒng)參與者，來識別每個安全目標的威脅 采用風險技術，識別和分析威脅的風險 對這些風險定義安全需求 一種表示法，圖示出與候選系統(tǒng)組件相關的場景路徑 基于情景的軟件工程技術，描述一個或多

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

31、系統(tǒng)建模的能力，這種系統(tǒng)可能在運行時改變情景和結構 電子商務應用 遠程通訊系統(tǒng) 簡單、直觀、易學 邊設計邊文檔化 不熟悉領域的開發(fā)人員學習領域知識的有效工具 經過直接的變換就可以轉化為消息序列圖、系統(tǒng)性能模型和測試用例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) 需求捕獲 體系結構評估 驗證和特征交互檢測 到設計和測試的轉換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)體系結構評估UserService PersonnelElevatorSchedulerStatus&PlanStatus&PlanElev. ControlElev. Mgrinelevatorabovebelowdecide ondirectionelsedoorclosemotorupmotordownmovingat floorupdownselectelevatorArrival Sensorapproachingfloornot requestedmotorstopdoor openstationary-memoryswitch ondoorclosing-delayadd tolistalreadyon liston listrequestedremovefrom listat requestedfloorArch. Alternative (II)體