中科院需求工程 基于情景的方法.ppt

需 求 工 程,金芝 中國科學院數(shù)學與系統(tǒng)科學研究院 zhijin,第七講：基于情景的方法,方法概述 情景分析和驗證 情景表示 一個基于情景的需求分析工具 情景研究新進展 小結(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 performers must work and use the system mcgraw k., 1994,從系統(tǒng)進化看情景方法的提出,重構(gòu)當前系統(tǒng)蘊涵的概念和理念 在概念層定義想要的改變 實現(xiàn)要改變概念構(gòu)成新的系統(tǒng) 與此同時，考慮遺產(chǎn)系統(tǒng),從系統(tǒng)進化看情景方法的提出,純模型方法的問題 能肯定這個模型真的反映了對變化的理解嗎？ 基于情景的方法 提供一個現(xiàn)實的，處于模型和現(xiàn)實之間的中間層抽象，可以克服這個問題 可能情景的數(shù)量遠遠多于給定系統(tǒng)的模型的數(shù)量，許多研究者認識到需要一個目標層次導出基于情景的處理,從系統(tǒng)進化看情景方法的提出,使用情景作為系統(tǒng)需求的表示，改善開發(fā)者和用戶之間的溝通 發(fā)現(xiàn)用戶的需要 將系統(tǒng)的使用方式嵌入系統(tǒng)開發(fā)過程中 系統(tǒng)地研究測定系統(tǒng)的行為（包括正常行為和異常行為） 與uml的用例緊密相關(guān),情景的作用以及與需求的關(guān)系,情景：與系統(tǒng)相關(guān)的定義,非形式的定義：完成系統(tǒng)預期任務的一個特定執(zhí)行實例所包含動作和事件的序列 開發(fā)情景的目的：模擬運作過程 情景的內(nèi)容，關(guān)于： 可能的出現(xiàn) 與這些出現(xiàn)相關(guān)的假設 可能的機會和風險 行為的過程,三種不同目的的情景,描述性的（descriptive）情景通過使系統(tǒng)分析師和用戶共同遍歷某一流程而理解流程相關(guān)的操作、參與者以及觸發(fā)流程的事件等因素。描述性的情景有助于對流程執(zhí)行的方式、流程的參與者以及流程啟動的方式和條件進行分類。 解釋性的（explanatory）情景確定系統(tǒng)要解決的問題并分析這些問題出現(xiàn)的基本原理。這類情景揭示為什么現(xiàn)實世界中會發(fā)生某些事件？是什么導致這些事件的發(fā)生？什么是這些事件的動因？以及哪些是經(jīng)常發(fā)生的和需要進行處理的事件？解釋性情景的描述要開發(fā)的系統(tǒng)所要求具有的功能。 探索性情景（exploratory）用于將需求與解決方案相關(guān)聯(lián)，對存在多種滿足系統(tǒng)需求的方案時非常有用，主要用于考查和評估這些方案，以得出其中最正確的方案。,不同抽象層次上的情景,實例情景包含帶實際參數(shù)值的特定名稱或事件。這類情景描述特定應用實例，作為討論需求的基礎(chǔ)，如：發(fā)生了什么，為什么發(fā)生以及如何發(fā)生的。 類型情景不定義單個情景實例而是定義情景實例的類型。因此類型情景不會涉及參與者王曉紅而只會涉及到顧客。類型情景的每一次執(zhí)行都是一個實例情景。 混合型情景中有些情景在實例級有些在類型級。,不同的情景表示,現(xiàn)實世界情景：現(xiàn)實世界事件發(fā)生序列，表示為敘事性文本、影象等，完全非形式表示 設計世界情景：想象中的目標系統(tǒng)相關(guān)的事件序列，表示為設計的故事、動畫型的動作序列，可能需要是結(jié)構(gòu)化表示，如表格和情景文本等，或形式化表示 模型情景：按照模型的語法語義要求的事件序列，采用形式化表示，如基于正則表達式或自動機等,情景在需求和設計中的作用,情景的優(yōu)點和缺點,將需求陳述和推理建立在具有一定細節(jié)的實例上，利于需求抽取 關(guān)注現(xiàn)實世界，解決具體的現(xiàn)實問題中的困難。質(zhì)問抽象模型難，判斷具體例子中的問題容易 情景可以作為測試案例測試規(guī)格說明和設計模型,從情景中泛化出抽象模型的過程不好理解（但結(jié)合情景的抽象模型上的推理卻幫助理解） 情景可能會導致對頻繁出現(xiàn)的事件的過度關(guān)注，對出現(xiàn)不夠頻繁的事件的忽略（必須保證情景的覆蓋面） 情景越多越好，但過多的情景增加開發(fā)的代價（情景集合的完整性和恰當性） 情景主要集中在功能性需求上,基于情景的需求分析,情景抽取（面談法）,can you give me an example of a situation that illustrates problems with information capture and transfer?,sure, i remember trying to get the 1994 quality report out. the information was there, but,情景描述的主要成分,目標和關(guān)鍵成功因素 物理上下文和邏輯上下文 組成情景的主要事件和活動 涉及的執(zhí)行者和其他參與者 要使用的信息和資源 要考慮的約束和要使用規(guī)則 需要作決策的點、要考慮的約束、要應用的規(guī)則 性能問題和提高的機會,比如：創(chuàng)傷診治情景的目標“讓病人得到及時并且合適的干預、運送和診治”，可能的子目標包括“管理緊急醫(yī)療資源，保證能處理多起創(chuàng)傷事故”，“避免非重創(chuàng)病人運送到創(chuàng)傷診治中心”，或者“選擇應用適當?shù)脑\治措施”,比如，適當分布診治中心（保證及時響應；創(chuàng)傷病人在診治的黃金時間到達診治中心；診治中心對任何可能發(fā)生創(chuàng)傷的地點來說都是在規(guī)定時間內(nèi)可達的；救治人員有能力判別創(chuàng)傷并快速進行干預；救治人員必須選擇適當?shù)倪\送方式,物理上下文：影響情景進行的物理條件，比如，情景中描述的執(zhí)行者和其他角色（包括使用的設備）處于的地點，活動發(fā)生的地點，以及它們之間的交互 邏輯上下文：事件發(fā)生的條件、業(yè)務情形、等，非物理世界的,情景中出現(xiàn)的基本過程、功能、活動，抽象出高層事件 過程、功能 / 高層事件 到達事故現(xiàn)場 / 場景評估、初步評估、決定救援需求 治療類選法 / 優(yōu)先級分配、計劃運送和干預 救治 / 運送方案選擇、處理和干預,情景描述的主要成分,目標和關(guān)鍵成功因素 物理上下文和邏輯上下文 組成情景的主要事件和活動 涉及的執(zhí)行者和其他參與者 要使用的信息和資源 要考慮的約束和要使用規(guī)則 需要作決策的點、要考慮的約束、要應用的規(guī)則 性能問題和提高的機會,比如：創(chuàng)傷診治情景的目標“讓病人得到及時并且合適的干預、運送和診治”，可能的子目標包括“管理緊急醫(yī)療資源，保證能處理多起創(chuàng)傷事故”，“避免非重創(chuàng)病人運送到創(chuàng)傷診治中心”，或者“選擇應用適當?shù)脑\治措施”,比如，適當分布診治中心（保證及時響應；創(chuàng)傷病人在診治的黃金時間到達診治中心；診治中心對任何可能發(fā)生創(chuàng)傷的地點來說都是在規(guī)定時間內(nèi)可達的；救治人員有能力判別創(chuàng)傷并快速進行干預；救治人員必須選擇適當?shù)倪\送方式,物理上下文：影響情景進行的物理條件，比如，情景中描述的執(zhí)行者和其他角色（包括使用的設備）處于的地點，活動發(fā)生的地點，以及它們之間的交互 邏輯上下文：事件發(fā)生的條件、業(yè)務情形、等，非物理世界的,情景中出現(xiàn)的基本過程、功能、活動，抽象出高層事件 過程、功能 / 高層事件 到達事故現(xiàn)場 / 場景評估、初步評估、決定救援需求 治療類選法 / 優(yōu)先級分配、計劃運送和干預 救治 / 運送方案選擇、處理和干預,情景分析,情景：用于描述一個存在系統(tǒng)以及它的環(huán)境的事實，包括主體(agents)的行為和進行系統(tǒng)需求發(fā)現(xiàn)和驗證的足夠的上下文信息 很多情況下，作為uml用例圖的擴展和補充 情景是系統(tǒng)使用的實例，常用于作為測試數(shù)據(jù)，和通過研究事件之間的關(guān)系來驗證需求,基于情景的需求分析,分析用戶目標，檢查是否需要系統(tǒng)功能的支持,得出系統(tǒng)目標，并引出系統(tǒng)功能需求,識別系統(tǒng)和用戶以及環(huán)境的交互,分析交互和所需求的功能，得出對輸入事件響應方式,根據(jù)輸入事件和系統(tǒng)目標，得出系統(tǒng)的輸出事件,分析系統(tǒng)輸出的用戶接受度，以及系統(tǒng)輸出事件的影響,分析系統(tǒng)輸出是否對用戶任務提供必要的支持，并且沒有帶來不希望的結(jié)果,進行涉眾性能價格比,用于評估系統(tǒng)輸出的影響，以及技術(shù)和社會系統(tǒng)的偶合,情景分析：知識表示框架,空間信息和物理環(huán)境事實,情景分析：倫敦救護車系統(tǒng),情景結(jié)構(gòu)模型,情景腳本,情景需求驗證：目標分析,目標分析啟發(fā)式 用戶目標需要計算機支持嗎？如果是，在需求規(guī)格說明中增加一條功能需求，否則增加非功能需求 目標描述系統(tǒng)應該實現(xiàn)的質(zhì)量或性能特性嗎？這些特性指定了可能不能直接實現(xiàn)的非功能性需求，非功能需求要和幫助實現(xiàn)它們的agents和活動相關(guān)聯(lián) 如果目標不要求計算機支持，它可以由手工過程達到嗎？這表明需要為社會系統(tǒng)活動做一個操作過程手冊 目標需要關(guān)于資源和職責的管理決策嗎？管理職責目標需要與情景模型中的合適的agent相連 情景目標和它所關(guān)聯(lián)的活動能夠完全自動化嗎？如果能，則將這部分情景模型轉(zhuǎn)換為需求規(guī)格說明，如果只需要部分自動化，則需要模型的進一步細化及其規(guī)格說明,情景需求驗證：目標分析,公眾：得到立即響應，救護車快速到達 救護車隊：獲得事故和發(fā)生地點的準確信息，以及完成這項任務的有用指令；盡快趕到事故地點；進行輔助醫(yī)務處理；盡可能安全快捷地送達醫(yī)院 派遣員：確定事故地點和優(yōu)先級，計劃最近最合適的救護車的派遣；監(jiān)控呼叫進展；獲得呼叫和救護車隊狀態(tài)的精確信息 經(jīng)理：提供有效的服務并縮減代價；優(yōu)化救護車和車隊資源的使用,情景需求驗證：目標分析,一些經(jīng)驗教訓： 許多目標只能由人工活動支持 規(guī)劃和調(diào)度是關(guān)鍵的活動，它們依賴于幾個目標，而且這些目標分別出自不同的涉眾 出現(xiàn)目標沖突情況 一開始自動調(diào)度系統(tǒng)是用于支持派遣任務的，但隨著分析的深入，這個支持顯得越來越不合適 雖然引入自動系統(tǒng)是為了減少人力和提高資源的使用率，但這個系統(tǒng)對車隊的支持卻很少,情景需求驗證：輸入事件依賴,通過跟蹤所有可能的輸入事件，檢查環(huán)境和系統(tǒng)的依賴關(guān)系 事件的來源： 環(huán)境中的agents，通常是產(chǎn)生系統(tǒng)輸入的人 環(huán)境中引起事件出現(xiàn)的對象，比如，風暴、動物橫穿馬路、等等 對信息系統(tǒng)，大多數(shù)事件出自人 對實時系統(tǒng)，許多事件源于物理世界或其它系統(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)要停止其它任務來響應它，如果不能，系統(tǒng)要報錯嗎？ 如果事件到達的次序不對怎么辦？系統(tǒng)是序列相關(guān)的嗎？如果是，需要緩存錯誤排序的事件并重新排序嗎？ 如果事件重復出現(xiàn)怎么辦？系統(tǒng)能檢測出重復嗎？如果能，要消除多余的事件嗎？ 如果沒有預想到的事件發(fā)生了怎么辦？系統(tǒng)能夠處理未知輸入嗎？系統(tǒng)能夠解釋無關(guān)的事件并報告嗎？ 如果傳錯了事件發(fā)生了怎么辦？系統(tǒng)能夠檢測出形式正確的事件的內(nèi)容被破壞了嗎？系統(tǒng)能夠請求事件發(fā)送者重發(fā)嗎？,情景需求驗證：輸入事件依賴,主要的三類事件蘊涵不同的系統(tǒng)響應： 可以驗證發(fā)生次序和時間的已知事件：系統(tǒng)需要對照事件歷史檢測事件次序，并采取錯誤矯正行為 可以在任何時候發(fā)生的已知事件：系統(tǒng)需要檢查事件發(fā)生的可能性，并提供回滾操作幫助矯正用戶錯誤，或者事件不正常出現(xiàn)時提示警告消息 未知事件：系統(tǒng)應該繼續(xù)正確地運行，需要例外捕獲過程，或者記錄機制，使研究人員可以研究例外事件。,情景需求驗證：輸入事件依賴,進一步的分析： 事件的來源可以跟蹤到某個特定個體嗎？如果可以，這個個體是否被授權(quán)發(fā)送這個事件？這個需求蘊涵識別消息來源和個體口令保護的日志。在網(wǎng)絡環(huán)境下，事件的來源難以檢測到，這個要求隱含了對授權(quán)協(xié)議的需求。 其它安全的考慮：事件消息可以被其他人看到嗎？如果事件必須保密，則需要加密,情景需求驗證：輸入事件依賴,倫敦救護車問題 呼叫重復：引出識別呼叫者、事故地點和情況的需求，以消除重復 不同結(jié)果的事件對資源的需求不同：引出分析事故結(jié)果的需求 情景腳本中的兩個報告事件是對報告事件的簡化，因為報告事件沒發(fā)生意味著可能的失效，引出對失效處理的需求 派遣員的指令是關(guān)鍵事件，準確的信息更是關(guān)鍵,情景需求驗證：分類系統(tǒng)輸出,系統(tǒng)輸出的形式 消息顯示 對話框 語音合成 需求說明形式： 列表 屏幕布局圖 故事板 原型界面,情景需求驗證：分類系統(tǒng)輸出,五種輸出事件類型 直接命令：要求人類采取行動的輸出信息 間接命令：可以是警告消息或者信息顯示，它們隱含人類應該采取行動 輸入請求：提示系統(tǒng)需要用戶的輸入 信息顯示：僅僅描述信息，并不隱含需要立即的響應 虛擬交互：模擬顯示，虛擬世界,情景需求驗證：輸出需求分析,任務：交叉檢索情景和需求規(guī)格說明，保證輸出在需要的時候被產(chǎn)生 提示問題：如果在情景腳本中，一個用戶在某個時間點需要某個信息，存在系統(tǒng)功能提供這個信息嗎？,情景需求驗證：輸出需求分析,核對表 針對需求規(guī)格說明，對每個產(chǎn)生輸出的組件，情景中存在相應的對該輸出信息的用戶需求嗎？ 在情景某個步驟上用戶需要的信息，該信息在它需要的時候能產(chǎn)生嗎？系統(tǒng)輸出和用戶任務的偶合依賴于應用的類型，安全系統(tǒng)中要求精確的同步 用戶需要這個信息是為了支持決策嗎？指出輸出需求，即系統(tǒng)應該提供信息幫助用戶作決策，或者提供執(zhí)行任務的指令 在情景中用戶的目的是尋找信息嗎？指出信息檢索需求,情景需求驗證：輸出需求分析,進一步的分析（適合性，這是用戶想要的嗎？） 系統(tǒng)輸出的信息內(nèi)容對用戶任務或目標來說合適嗎？,情景需求驗證：輸出需求分析,進一步的分析（安全性） 誰應該得到這個輸出信息？ 收到信息的人不對怎么辦？需要加密功能 輸出丟失了怎么辦？需要登記消息日志、消息重發(fā)的功能 輸出到的太早或太晚怎么辦？需要時效控制功能 輸出到達的次序不對怎么辦？需要保證輸出順序的功能 如果輸出信息不允許流傳，需要跟蹤輸出目的地，獲得身份認證等的功能，以保證到達正確的目的地，防止非法訪問,情景需求驗證：輸出需求分析,倫敦救護車問題 直接輸出： 直接命令：派遣員到救護車隊的命令 信息顯示：事故的位置和狀態(tài)，救護車行駛的情況，車隊和呼叫的分配關(guān)系,情景需求驗證：輸出需求分析,倫敦救護車問題 系統(tǒng)輸出的使用： 車隊需要交通擁堵和道路狀況信息（未提供，因為車隊和系統(tǒng)沒有直接的交互） 派遣員交通擁堵和道路狀況信息，以支持其進行正確的決策 派遣指令傳送的正確性，要求車隊身份認證 指令丟失導致呼叫無響應，重復指令會導致重復派遣，指令次序錯誤會引起車隊混亂，要求指令通訊的正確無誤 不正確的指令導致系統(tǒng)混亂，要求交叉檢查指令的準確性和正確性,情景需求驗證：社會影響分析,困難的任務，因為 不知道準確的社會理論，來預計人類用來應對計算機系統(tǒng)的行為 缺少足夠的特定社會系統(tǒng)的知識來做這個預計 缺少穩(wěn)定的社會環(huán)境，使得在系統(tǒng)被夠建出來后這個預測仍然有效,情景需求驗證：社會影響分析,一些可能的考慮點： 評估社會系統(tǒng)和技術(shù)系統(tǒng)的偶合度 系統(tǒng)輸出記數(shù) 緊偶合加大了二者的依賴程度，導致系統(tǒng)容易出錯 設計一些自治的子系統(tǒng)來減少偶合度 社會系統(tǒng)的文化影響對偶合度的容忍程度，層次式組織結(jié)構(gòu)容易容忍緊偶合，網(wǎng)絡化組織適合于松偶合,情景需求驗證：社會影響分析,一些可能的考慮點： 情景結(jié)構(gòu)模型的不同細化，產(chǎn)生不同的系統(tǒng)邊界，導致不同的（人和機器之間）任務分配 過多的自動化會削弱人的職責 過多的自動化會削弱人對整個系統(tǒng)的意識，導致人對意外處理的能力下降 強迫人做他不想做的任務的這種自動化，增加人的抵觸情緒 強加給人很多新任務的緊偶合自動化，用不自然的方式限制了人類的活動，也會增加人的抵觸情緒 人與自動系統(tǒng)的偶合應該對用戶的知識和技能敏感 自動系統(tǒng)的引入不能改變?nèi)伺c人之間的職責關(guān)系和權(quán)利關(guān)系,情景需求驗證：社會影響分析,在系統(tǒng)邊界確定之后，進行輸出結(jié)構(gòu)影響分析，考慮系統(tǒng)輸出是否能實現(xiàn)用戶目標，授權(quán)關(guān)系是否清楚，是否沒有沖突。 信息輸出的影響分析： 信息輸出給每個agent會增加他的權(quán)利嗎？會削弱其他agent的權(quán)利嗎？ 輸出的信息會被惡意使用嗎？ ,情景需求驗證：社會影響分析,情景結(jié)構(gòu)模型用于影響分析，第一步評估命令影響的啟發(fā)式： 系統(tǒng)的這個輸出觸發(fā)了人類agent負責的一個活動嗎？如果是這就是一個直接命令 系統(tǒng)的這個輸出對人類agent的一個決策活動是必須的嗎？如果是這就是一個間接命令 系統(tǒng)的這個輸出對人類agent完成一個活動有幫助嗎？如果是這就是一個間接依賴,情景需求驗證：社會影響分析,情景結(jié)構(gòu)模型用于影響分析，第二步評估目標、職責、作用和授權(quán)等的啟發(fā)式。對每個輸出命令，評估將涉及的agents： 檢查agent的特性確定他們是否具備必要的技能或知識來執(zhí)行這個任務，如果不是，隱含需要人員選拔或培訓 檢查agent的作用和任務，如果這個命令給的人錯了，隱含需要改變社會系統(tǒng) 檢查agent是否能夠按時并按合適的方式來響應這個命令，研究制定決策或者執(zhí)行任務的時間要求,情景需求驗證：社會影響分析,情景結(jié)構(gòu)模型用于影響分析，第三步檢查用戶是否可能接受這個命令： 命令會導致組織職責分配的無序嗎？要求一個agent接受一個超出職責范圍的決定 命令破壞了用戶的授權(quán)嗎？系統(tǒng)需要用戶在錯誤的時間接受一個決定 命令改變了人類agents之間的權(quán)利關(guān)系嗎？命令削弱了一個agent的權(quán)利而增加了另一個agent的權(quán)利,情景需求驗證：涉眾分析,對每類涉眾： 新系統(tǒng)降低了他們工作的技能嗎？（過度自動化） 新系統(tǒng)威脅到他們工作的保密性嗎？ 他們的職責將被新系統(tǒng)削弱嗎？（自動化或者職責重新分配） 系統(tǒng)影響工作積極性嗎？（過度偶合、太不靈活、剝奪自主性、沒有提供足夠的信息、等）,情景需求驗證：涉眾分析（案例）,情景需求驗證：涉眾分析（案例）,情景形式化表示工具,基于時間區(qū)間的情景表示 嚴格順序：ev(enda)ev(endb) and (ev(enda)ev(endb) 并發(fā)： 交替：(ev(starta) occurs) or (ev(startb) occurs) 并行：(ev(starta)=ev(startb) and (ev(enda) = ev(endb) 同時開始：(ev(starta)=ev(startb) and (ev(enda) not= ev(endb) 同時結(jié)束：(ev(starta) not= ev(startb) and (ev(enda) = ev(endb),一個基于情景的需求分析工具 scram,scram：基于情景的需求分析,情景用來早期原型化抽取需求 提供集成的技術(shù)，讓用戶積極參與，得到用戶的有效反饋 利用情景作為背景討論設計方案、引出新的需求,scram,傳統(tǒng)的面談法等信息采集技術(shù),為要構(gòu)造的系統(tǒng)創(chuàng)建早期的想象,通過故事板向用戶解釋并獲取反饋,通過概念展示器和早期原型向用戶表現(xiàn)更細的設計,進行情景驅(qū)動的,半交互式的證明,開發(fā)更全面的功能原型,并繼續(xù)求精需求,直到原型被所有用戶接受,scram：故事面板,概念展示器：上下文情景（例）,本船是一艘現(xiàn)代運輸船（3萬噸），有36個船員和5個管理人員（國際化），上午10點離開南開普頓，向方向開進，現(xiàn)在位置在，現(xiàn)在的氣象條件好，能見度15英里，西北風，風力3級。 下午3:10pm，一個船員報告發(fā)現(xiàn)在2號船艙發(fā)現(xiàn)煙霧，發(fā)出火警信號,從船長任務產(chǎn)生情景腳本,研究發(fā)生火警的位置，如果必要向船員發(fā)出疏散命令 如果有，啟動自動火警撲滅系統(tǒng) 廣播命令，讓船員開始救火 分配初級管理人員領(lǐng)導救火隊 檢查船貨，看是否有危險品靠近火警點 計劃救火策略，考慮危險品和其它災害 發(fā)布救火指令，監(jiān)控救火過程，直到火警消除,scram：概念展示器,從情景腳本到設計問題,情景與uml用例,再論情景的定義,情景是事件的序列 從用例的角度看： 是穿越用例的一條可能的路徑 情景是從用例中導出的行為/活動的序列 每個用例可能導出多個情景 對由多個情景組成的集合進行推理，需要適當?shù)谋磉_手段和推理機制,基于區(qū)間的時間推理,基本假設： 區(qū)間是表示時間的基本單位 時間是度量客觀事件發(fā)生的先后和延續(xù)性的一種標準 客觀事件的發(fā)生總是有一個過程 區(qū)間長度一般不為零 有兩個時間點：起點t(a)-和終點t(a)+ 基本假設：時間區(qū)間是半開半閉的,七種時間關(guān)系,假設a、b表示兩個時間區(qū)間 a在b之前：ab，具體特征：t(a)+ t(b)- a等于b：a=b，具體特征：t(a)- = t(b)-， 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結(jié)束b：a e b，具體特征：t(b)- t(a)- t(a)+ = t(b)+,從用例片段到情景,從用例片段到情景,買賣用例中的事件 事件a：賣方拿起電話 事件b：買方請求報價 事件c：交易系統(tǒng)顯示價格 事件d：賣方拒絕買賣 事件e：賣方檢索價格信息 事件f：,從用例片段到情景,從用例片段到情景,事件之間的時間區(qū)間關(guān)系 a在b之前：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ù)時間關(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)+,從用例片段到情景,情景支持的輕量級形式化方法,情景和類模型的一致性檢測 將情景和類圖等結(jié)構(gòu)顯式地表示出來，并對所有的圖元進行命名 定義一些檢測的規(guī)則，包括 可形式檢測的規(guī)則，如： 名一致性規(guī)則 語法正確性規(guī)則 引用正確性規(guī)則 人工檢測的規(guī)則，如： 重疊最小化 避免缺少信息 內(nèi)容的對應性 信息流的充分性 關(guān)于領(lǐng)域特性的規(guī)則,用于一致性檢測的元模型,反例建模,誤用用例，misuse case 濫用用例，abuse case 一個可以被任何人或?qū)嶓w為了破壞系統(tǒng)的進行的行為序列 表示系統(tǒng)應該避免的應用場景 誤用戶，misuser 觸發(fā)誤用用例的參與者，有意的或無意的,反例建模,誤用用例圖：關(guān)系 一般用例中的關(guān)系： include extend generalize association 新的關(guān)系 mitigate：一個用例能夠減少一個誤用用例成功的機會 threaten：一個誤用用例能夠?qū)σ粋€用例產(chǎn)生威脅，比如利用一個用例，或者阻止一個用例，來達到它的目的,反例建模,從誤用用例中識別安全需求 識別系統(tǒng)中的關(guān)鍵資產(chǎn) 對每個關(guān)鍵資產(chǎn)，定義安全目標 通過識別想要危害這個系統(tǒng)的系統(tǒng)參與者，來識別每個安全目標的威脅 采用風險技術(shù)，識別和分析威脅的風險 對這些風險定義安全需求,應用情景圖（use case maps）,從誤用用例中識別安全需求 識別系統(tǒng)中的關(guān)鍵資產(chǎn) 對每個關(guān)鍵資產(chǎn)，定義安全目標 通過識別想要危害這個系統(tǒng)的系統(tǒng)參與者，來識別每個安全目標的威脅 采用風險技術(shù)，識別和分析威脅的風險 對這些風險定義安全需求,應用情景圖（use case maps）,一種表示法，圖示出與候選系統(tǒng)組件相關(guān)的場景路徑 基于情景的軟件工程技術(shù)，描述一個或多個用例的職責之間的因果關(guān)系 用類似路徑圖的形式顯示有關(guān)的用例,ucm表示法 基本部分,ucm例: 通勤,準備 好離 開家,在辦 公室,responsibility point,basic path (from circle to bar),component (generic),為什么用應用情景圖?,橋接需求和設計之間的建模鴻溝 用顯式可視化的方式連接行為和結(jié)構(gòu) 為高層設計層的體系結(jié)構(gòu)決策提供行為框架 一旦體系結(jié)構(gòu)出來后，刻畫體系結(jié)構(gòu)層的行為 在一個圖中表達了很多方面的信息 集成了一個情景，便宜推斷出潛在的不希望出現(xiàn)的情景交互,為什么用應用情景圖?,提供為動態(tài)系統(tǒng)建模的能力，這種系統(tǒng)可能在運行時改變情景和結(jié)構(gòu) 電子商務應用 遠程通訊系統(tǒng) 簡單、直觀、易學 邊設計邊文檔化 不熟悉領(lǐng)域的開發(fā)人員學習領(lǐng)域知識的有效工具 經(jīng)過直接的變換就可以轉(zhuǎn)化為消息序列圖、系統(tǒng)性能模型和測試用例,應用情景圖處于什么位置？,ucm表示法 層次結(jié)構(gòu),ucm example: commuting,ready to leave home,in cubicle,secure home,commute,take elevator,dynamic stub (selection policy),static stub,stay home,ucm表示法 簡單插裝,ucm example: commute - car (plug-in),ucm表示法 and/or,ucm example: commute - bus (plug-in),and fork,or join,or fork,and join,ucm表示法 動態(tài)結(jié)構(gòu),generic ucm example,start,end,dynamic responsibilities and dynamic components,pool a,pool b,create,create,copy,destroy,destroy,move out,move into,move into,slot (component),pool (component),應用情景圖的使用,需求捕獲 體系結(jié)構(gòu)評估 驗證和特征交互檢測 到設計和測試的轉(zhuǎn)換,user,select destination,the elevator control system case study is adapted from hassan gomaas designing concurrent, distributed, and real-time applications with uml (p459-462), copyright hassan gomaa 2001, published by addison wesley. used with permission.,需求捕獲,user,arrival sensor,service personnel,scheduler,elevator,in elevator,above,below,decide on direction,else,door close,motor up,motor down,moving,at floor,up,down,select elevator,approaching floor,not requested,motor stop,requested,door open,at requested floor,stationary- memory,switch on,door closing-delay,add to list,on list,already on list,remove from list,arch. alternative (i),體系結(jié)構(gòu)評估,user,service personnel,elevator,scheduler,status&plan,status&plan,elev. control,elev. mgr,in elevator,above,below,decide on direction,else,door close,motor up,motor down,moving,at floor,up,down,select elevator,arrival sensor,approaching floor,not requested,motor stop,door open,stationary- memory,switch on,door closing- delay,add to list,alrea