《需求工程方法》PPT課件.ppt

1、第四講：需求工程方法,目標分析方法 領域工程與面向特征的領域分析,面向目標的方法,方法概述 建模原語 基于目標的建模和分析 應用情況,面向目標的方法,What You Get Is What You Want (WYGIWYW),什么是目標,什么是目標? A goal is an objective that the system under consideration should achieve Goal formulations refer to intended properties to ensured They are optative statements as opposed

2、to indicative ones, and bounded by the subject matter,什么是目標,不同層次的目標,高層策略 型目標,低層技術 型目標,運送更多旅客,提供隨處可用的提現(xiàn)服務,及時發(fā)出加速指令,3次密碼錯誤則不退卡,策略性的、粗粒度的、作用于組織范圍的抽象目標,技術性的、細粒度的、作用于系統(tǒng)設計層面的具體目標,什么是目標,不同類型的目標 功能性目標：要實現(xiàn)的服務，是需求相關者期望發(fā)生的所有場景的集合。 非功能性目標：與提供服務的質量關聯(lián)，如良好的保密性，較高的安全性，較強的準確性，較好的易用性等 ，或者對開發(fā)過程質量的期望，例如良好的適應性，較強的互操作性，較

3、高的可重用性等 酒店管理系統(tǒng)的功能性目標：盡可能滿足所有客人的房間預定請求 圖書管理系統(tǒng)的非功能性目標：用戶的每一次查詢都能夠盡快地返回結果,什么是目標,目標由誰來滿足：整個系統(tǒng) 火車運輸系統(tǒng)： 目標：安全運輸 參與者：火車司機、列車軌道、車站計算機、通訊設備、旅客、等等 ATM機系統(tǒng)： 目標：允許合法用戶提取現(xiàn)金 參與者：ATM軟件、感應器/actuators、用戶、等等,目標類型和層次,可滿足性還不明確,可滿足性可以驗證,產生行為使得目標特性在將來總要被滿足（拒絕）,限制行為要求目標特性在將來永久保持（拒絕）,比較行為，偏向更好保證軟目標特性行為,提供信息的目標,滿足請求的目標,采用目標的

4、好處,目標分析提供一種關于系統(tǒng)的全局的視角 目標的滿足由整個系統(tǒng)及環(huán)境主體共同完成。例如： 鐵路運輸系統(tǒng)的安全性目標是由火車司機、軌道管理系統(tǒng)、車站管理系統(tǒng)、通訊設備、乘客等共同參與完成的； ATM系統(tǒng)保持用戶合法性的目標是由ATM控制軟件、感應器、效應器、用戶等共同協(xié)作完成的。 只有采用全局的俯瞰的視角才能有效地分析和解決這類目標。,采用目標的好處,保證需求的完整性 目標是需求足夠完整的精確評判標準 規(guī)格說明相對于一組目標是完整的， 如果可以證明所有目標（G）是能實現(xiàn)的 由規(guī)格說明（S）和所涉及的領域的特性（D）D，S |= G = S相對于G是完備的,采用目標的好處,避免無關需求（最小性）

5、 目標是需求相關性的精確評判標準 需求相對于一組關于所涉及領域的目標是恰當或相關的， 如果其規(guī)格說明至少被用來證明一個目標 若sS， g G ，D，s |= g = S相對于G是最小相關的,采用目標的好處,向需求相關者解釋需求 目標給出了需求的說明對應于設計過程中的設計目標 出現(xiàn)一個需求是因為有一個目標作為它的基礎 目標求精樹提供了從高層策略目的到低層技術需求的可跟蹤鏈 對業(yè)務系統(tǒng)來說，目標將未來軟件和組織和業(yè)務上下文關聯(lián)起來,采用目標的好處,目標精化過程，為復雜需求文檔的結構化提供直觀自然的機制，增加其可理解性 目標精化過程中的選擇，具有恰當?shù)某橄蟪潭?采用目標的好處,目標便于表達和處理沖突

6、需求。 目標的沖突是多視點沖突的根源， 目標的不同滿足標準有助于幫助開發(fā)人員對采用哪種方式處理沖突進行決策。,采用目標的好處,目標相對比較穩(wěn)定，利于需求演化 實現(xiàn)目標的需求比目標演化的要快，它很容易被另一個實現(xiàn)相同目標的需求替代 越高層的目標越穩(wěn)定，不同版本的系統(tǒng)常常具有相同的高層目標,采用目標的好處,目標能夠表達和分析非功能性需求。 非功能性需求是工程研究中的重點和難點，目前大多采用非形式化的方法來描述， 常用的建模工具UML也存在著難以為非功能性需求建模的缺陷。 在面向目標的需求分析中，非功能性需求用軟目標來表示，軟目標可以逐步分解為子目標,目標從何而來？,顯式的 系統(tǒng)的需求相關者（Sta

7、keholders） 需求工程師掌握的初步材料,目標從何而來？,隱式的：需要進行目標抽取 分析當前的系統(tǒng)，發(fā)現(xiàn)問題和不足（精確構型并列舉出來），對其取否，導致未來系統(tǒng)要實現(xiàn)的目標集 從初步文檔中尋找一些與意圖相關的關鍵詞發(fā)現(xiàn)目標 對目標進行精化和抽象獲得 歸結目標沖突或障礙導致新的目標,目標什么時候顯式化？,顯式化：從目標到軟件行為 用軟件行為實現(xiàn)目標等同于用程序實現(xiàn)設計規(guī)格說明,方法主線：元模型,領域中所關心的事情，其實例會按狀態(tài)而進化,對象上的輸入/輸出關系，定義狀態(tài)變遷，由事件觸發(fā)或終止,一種對象，作為行為的執(zhí)行者,操作化目標，可以按由某個Agent可控制的狀態(tài)來構型的目標,方法主線,建

8、模主線：系統(tǒng)的目標層次結構。 圍繞目標的伸展關聯(lián)： 目標操作化為“約束”， 約束由“活動”和活動所操作的“對象”來保證， 對象被區(qū)分為“事件”、“實體”、“關系”和“主體”四類， 約束由主體負責完成， 主體執(zhí)行活動并具有活動的能力， 事件可以觸發(fā)或者終止活動，等等 可以通過在目標樹上添加標記來表示目標間的正向和負向的強弱影響。,目標的表示,目標名：每個目標都有名字 簡短描述：自然語言陳述句描述 例如： 用戶提出“要為核電站設計安全的制冷系統(tǒng)”。則“安全的核電站制冷系統(tǒng)”將作為一個高層抽象目標的描述被抽取出來。 會議調度系統(tǒng)要滿足的目標之一是“每個會議都將在所有預期與會人參加的情況下召開?！?目

9、標的形式化表示,KAOS語言，NFR建?？蚣芤约癷*/Tropos語言：特定的語法 一階時序邏輯斷言算子： P表示“在當前狀態(tài)下，性質P成立”； P表示“在下一個狀態(tài)，性質P成立”； P表示“在當前或未來某一狀態(tài)，性質P成立”； P在當前以及未來所有狀態(tài)，性質P成立； P在前一個狀態(tài)，性質P成立； P在當前或以前某一狀態(tài)，性質P成立； P在當前和以前所有狀態(tài)，性質P成立；,目標的形式化表示,PQ在所有未來狀態(tài)，性質P成立則性質Q成立； ku P在k個時間單位u以內的未來某一狀態(tài)，性質P成立； d P在截止時刻d到達前的未來所有狀態(tài)，性質P成立； P在當前狀態(tài)下性質P成立，但在上一個狀態(tài)，P不成

10、立； PW Q在所有未來狀態(tài)下，性質P成立直到Q成立，允許Q恒假； PU Q在所有未來狀態(tài)下，性質P成立直到Q成立，Q必須在未來某一時刻為真。,目標模式,完成型目標（Achieve）：要求系統(tǒng)最終滿足某性質； 終止型目標（Cease）：要求系統(tǒng)最終不再滿足某性質； 維持型目標（Maintain）：要求系統(tǒng)始終滿足某性質； 避免型目標（Avoid）：要求系統(tǒng)從不滿足某性質。,目標模式的規(guī)約,完成型目標(Achieve)：P Q 語義：如果P成立，則將來某個時候Q成立 維持型目標(Maintain) ：P Q 語義： 如果P成立，則將來Q總成立 P P W Q 語義：維持P成立直到Q成立 終止型目

11、標(Cease)：P Q 語義： 如果P成立，則將來某個時候Q不成立 避免型目標(Avoid)：P Q 語義： 如果P成立，則將來Q總是不成立,目標分類,滿足性目標（Satisfaction Goals）：是滿足各主體愿望的完成型目標； 信息目標（Information Goals）：是將環(huán)境狀態(tài)信息通報給主體的完成型目標； 安全目標（Security Goals）：是避免災難狀態(tài)/惡意攻擊發(fā)生的持續(xù)型目標； 精確性目標(Accuracy Goals)：是促使主體對環(huán)境的信念保持精確的持續(xù)型目標。,目標的圖形表示,除了自然語言和形式化表示，目標還有圖形化的表示，通常都是在目標圖元中加目標名。

12、在KAOS中，目標的圖形表示是一個平行四邊形（ ）。在i*/Tropos中，目標的圖形表示是圓角的矩形（ ）。,軟目標,軟目標主要用于表達非功能性需求。 軟目標與一般目標的主要區(qū)別： 一般目標的滿足性標準是客觀的，能夠清楚定義和表達的。 軟目標的滿足標準則是主觀的、相對的、依評價者的個人判斷而定，是滿意度（Satisficing）而非滿足性（Satisfying）的問題。,軟目標的表示,NFR框架：軟目標的圖形化表示為一個云形（ ） i*和Tropos方法：軟目標圖形化表示為一個不規(guī)則的花生形（ ）。,軟目標的組成,非功能性軟目標通常由兩部分組成：類型和主題。例如， 軟目標“賬戶的準確性”中，

13、“準確性”是類型，“賬戶”是主題。 如果類型改變?yōu)椤绊憫獣r間”則軟目標“賬戶響應時間”的含義也隨之改變。 當主題發(fā)生改變，軟目標的含義也隨之改變。 “賬戶的準確性”與“賬戶的響應時間”，或與“存款機的響應時間”是完全不同的。 一種略微結構化的軟目標表示方法是：“軟目標類型軟目標主題”，例如， 用“響應時間短賬戶”來表示軟目標“賬戶的響應時間”。 軟目標可以有多于一個主題，例如， 界面靈活性普通客戶，金卡賬戶。,目標的操作化,可操作的目標是對目標與軟目標進行分解和求精的結果。 可操作的目標是目標分解樹中靠近底層葉節(jié)點的目標，用于表示滿足高層目標的具體設計方案。例如： 要實現(xiàn)“快的帳戶響應時間”這

14、個軟目標，可以“采用索引技術”，“采用索引技術”就是一個可操作的目標。,可操作目標的表示,NFR框架：圖形表示為邊界加重的云形圖案 KAOS：圓角的矩形 i*和Tropos：表示為任務,目標間的關聯(lián),目標間的關聯(lián)： 自頂向下的分解關系 自底向上的貢獻關系 橫向的副作用關系,目標的分解,目標分解： 與精化：目標到一組子目標 語義：所有子目標被滿足，父目標才被滿足 或精化：目標到一組精化選擇 語義：只要一個選擇被滿足，足以讓父目標滿足 軟目標的分解（軟目標類型主題對象） 按軟目標類型進行分解 按軟目標對象進行分解 軟目標的操作化,目標的貢獻,一個高層的、抽象的、粗略的軟目標可以分解為相對低層的、具

15、體的和細化的子（軟）目標或操作化目標。 每個單個的子目標可以對父目標的滿足性產生出不同的貢獻。 貢獻類型分為兩個維度： 貢獻的影響和貢獻的程度。 貢獻的影響可以是正向、負向或未知； 貢獻的程度可以是完全的、部分的或程度未知。,目標的副作用關系,副作用包括貢獻副作用和沖突副作用。例如： “提高性能”會導致“成本提高”，是橫向副作用關系，表明一種沖突。即一個目標被滿足會阻止另一個目標的滿足。 “信息的保密性”會提高“信息的安全性”，也是橫向副作用，表明一種貢獻。即一個目標被滿足會幫助另一個目標的滿足。,建模原語：目標與/或樹,建模原語：其它關聯(lián),目標與其它需求建模元素的關聯(lián) 目標與操作：操作的前提

16、條件、后置條件、觸發(fā)條件，保證目標目標的可滿足性 目標與情景：互補 情景：具體、敘述性、過程性、意圖隱含于其中 目標：抽象、描述性、顯式展現(xiàn)意圖 更進一步，情景可以是例子或者是反例，可以展示目標的實現(xiàn)過程，也可以表現(xiàn)阻止目標可滿足的情況,建模原語：其它關聯(lián),目標與其它需求建模元素的關聯(lián) 目標模型與對象模型：具體的目標可以涉及實體、關系或者agent，支持從目標模型系統(tǒng)化地導出對象模型 目標與Agents：職責關系，將目標賦予一個Agent完成，有利于識別系統(tǒng)的邊界 形成目標結構,目標形式化表示框架,Goal 目標模式目標名 InstanceOf 目標分類 Concerns 對象集合 Refin

17、edTo 子目標 InformalDef 自然語言陳述 FormalDef 一界時態(tài)邏輯公式,目標形式化表示舉例,Goal Achieve TrainProgress FormalDef Goal Maintain TrainWaiting FormalDef,Goal Achieve ConvenientMeetingHeld Definition “每個會議都將在所有預期與會人參加的情況下召開” FormalDef m: Meeting: m.Requested m.Holds ( p: Participant): Intended (p, m) Participates (p, m),目

18、標形式化表示舉例,Goal AchieveParticipantsConstraintsKnown InstanceOf InformationGoal Concerns Meeting, Participant, Schedule, RefinedTo ConstraintsRequested, ConstraintsProvided InformalDef A meeting scheduler should know the constraints of the various participants invited to the meeting within C days after

19、 appointment FormalDef m:Meeting, p:Participant, s:Scheduler Invited(p,m)Scheduling(s,m) =Cd Knows(s,p,Constraints),目標模式,目標名,目標類型,關注的對象,兩個子目標,語義定義,目標模型中的其它概念,對象： 客觀世界領域中所關注的事情， 可能是按狀態(tài)進化的。 比如：實體、關系、事件 Agent： 一種特殊的對象 作為行為的執(zhí)行機制，如果該行為被分配 知道一個對象，如果該對象的狀態(tài)對它來說是可觀察的話 可以是人、設備、程序、等等,Agent形式化表示舉例,Agent Staff/主

20、體定義 Has competenceArea, /主體屬性 Invariant /主體不變式 ( st: Staff) (InstanceOf (st: ResearchStaff)InstanceOf(st, SecretaryStaff) Load CapableOf /主體能力集合 AddCopy, RemoveCopy, BiblioQuery, CheckOut, Return, IssueReminder, Performs /主體動作集合 AddCopy, RemoveCopy, Knows /主體知識集合 Borrowing Interface: BorrowingSheet,

21、 ,Agent形式化表示舉例,Agent Participant CapableOf CommunicateConstraints, Has Constraints: TupleExcludedDates:SeqOfTimeInterval, PreferredDates:SeqOfTimeInterval,關系形式化表示舉例,Relationship Invited Links Participantscard:0:N，Meetingcard:1:N DomInvar p:Participant, m:Meeting Invited(p,m)pRequesting-, m. Particip

22、antsList,目標模型中的其它概念,行為/操作： 對象之間的輸入、輸出關系，其數(shù)學含義是作用于對象集合之上的關系。動作導致狀態(tài)遷移。 動作通過前置條件、后置條件和觸發(fā)條件來定義： 前置條件：動作執(zhí)行的起始狀態(tài)需要滿足的最弱必要條件 觸發(fā)條件：動作執(zhí)行的起始狀態(tài)需要滿足的最弱充分條件 后置條件：動作執(zhí)行的終止狀態(tài)需要滿足的最強條件 條件被區(qū)分為兩大類： 領域（domain）前置和后置條件，描述操作所引發(fā)的領域中的基本狀態(tài)遷移， 需求（Required）前置和后置條件，描述該操作為確保需求的滿足要引發(fā)的額外狀態(tài)遷移。,行為/操作形式化表示,Action 行為名 Input 行為輸入 Outpu

23、t 行為輸出 DomPre 領域前置條件 DomPost 領域后置條件 RequiredPre 行為執(zhí)行的前置條件 RequiredPost 行為執(zhí)行的后置條件,行為形式化表示舉例,Action CheckOut/動作定義 Input BookCopy Arg: bc, Library Arg: bor /動作輸入參數(shù) Output Library Res: lib/動作輸出參數(shù) PreCondition bc lib.available/動作前、后置條件 PostCondition bc lib.available bc lib.checkedOut Borrowing(bor, bc) A

24、ction IssueReminder/動作定義 Input Borrower Arg: bor, BookCopy Arg: bc /動作輸入參數(shù) Output Reminder/動作輸出參數(shù) TriggerCondition /動作觸發(fā)條件 2wBorrowing(bor, bc) 1w ( r: ReminderIssued) Occurs(r) r = (bor,bc, -) PostCondition /動作后置條件,行為形式化表示舉例,Action DetermineSchedule Input Requesting, MeetingArg:m Output MeetingRes:

25、m DomPre Requesting(-,m)Scheduled(m) DomPost Feasible(m)Scheduled(m) Feasible(m)DeadEnd(m),行為形式化表示舉例,Action Move Input tr:Train; loc,loc: Location Output At DomPre At(tr,loc) and locloc DomPost At(tr,loc) RequiredPre for DoorsClosedWhileMoving: tr.Doors=closed RequiredPost for DoorsClosedWhileMoving

26、: tr.Doors=closed,目標模型中的其它概念,約束（Constraint）： 可實現(xiàn)的目標，即能夠根據主體可控制的狀態(tài)來構型的目標。 所有的目標最終都將精化為約束， 約束被操作化為動作和對象， 約束要被分配給主體來完成。,約束形式化表示舉例,WeakConstraint MaintainAgendaUpToDate/約束定義 InstanceOf ConsistencyConstraint/約束實例 UnderResponsibilityOf Participant/約束的責任主體 FormalDef/約束的形式化描述 ( p: Participant, tp: Timeinter

27、val ) Free(p, tp) tp BusyPeriods,目標模型中的其它概念,情景（Scenario）： 由相應主體實例控制的領域相容的狀態(tài)遷移序列。 領域相容性是指當操作的領域前置條件和操作涉及對象的領域不變式滿足時，運用該操作所導致的后置條件將滿足領域后置條件。 依據情景定義找出規(guī)約中遺漏的動作和隱含的目標。,情景形式化表示舉例,Scenario HandleMeetingRequest/情景定義 Is (IssueRequest:SubmitRequest; ValidateRequest); /動作序列 AskParticipantsConstraints; (GetCons

28、traints: FormulateConstraints; CommunicateConstraints; ValidateConstraints)*; PlanMeeting; (NotifyResults: (NotifyDate&Location | NotifyDeadEnd),需求抽取和建模過程,以元模型為基礎的需求抽取,需求抽取過程和策略,策略：遍歷元模型圖來獲取實例 獲取目標結構： AND/OR結構（HOW：抽取子目標；WHY：提取父目標） 識別有沖突的目標 將目標逐步精化為可實現(xiàn)的約束 標識目標涉及的對象 描述對象的領域特性 識別對象有意義的狀態(tài)變遷（行為的前置條件和后置條件

29、） 定義行為保證約束的可滿足性 識別系統(tǒng)的相關主體，確定主體的職責，并將行為賦予主體,目標的精化：基本思路,一組目標G1,G2,Gn是目標G的完全精化，當且僅當 G1,G2,Gn |- G (必要性) G1,G2,Gn |- false (一致性) n 1（非平凡性） Forany 1jn, G1,Gj-1,Gj+1,Gn |- G (最小性),目標的精化：精化模式,抽象目標斷言的一級與樹分解，使得葉子斷言的集合是根斷言的完全求精,目標精化策略,時間驅動：尋找中間狀態(tài)，按目標滿足的先后次序劃分子目標 主體驅動：按參與目標實現(xiàn)的主體集合進行目標劃分，使子目標有較少的主體參與 案例驅動：按照案例分

30、析進行劃分，比如：正常案例和例外案例,精化模式：實現(xiàn)型目標的精化,實現(xiàn)型目標的兩種精化模式 時間驅動的分解 PQ：PR，RQ 案例驅動的分解 PQ：PRQ， PR (PR) P (PR)； PRRP PPU (PR)；PRP， PRR PR， PP；PP，RR,精化模式：實現(xiàn)型目標的精化,精化模式的作用,支持形式化推理 幫助檢測不完全的精化 幫助開拓需求 使各種選擇顯式化,其它目標精化模式,實現(xiàn)型目標 PQ：PRQ，PR， PPWQ PQ：PR， RQ PQ：PR， RRUQ PQ：PP1Q1，PP2Q2， （P1P2） Q1Q2Q ,目標的操作化,激勵響應模式 安全需求模式 ,激勵響應模式目

31、標精化,可操作的約束,可操作的約束,可操作的約束,安全需求精化模式,可操作的約束,可操作的約束,可操作的約束,從約束到行為,案例研究舊金山灣區(qū)快速交通系統(tǒng)（BART),步驟和模型,四個子模型 目標模型、對象模型、Agent職責模型、操作模型 開發(fā)步驟 目標抽取和精化（目標精化） 從目標模型中導出對象、關系和屬性（對象建模） 識別Agent以及Agent的職責（職責分配） 定義操作及其前置條件和后置條件（操作化）,目標識別,按關鍵詞尋找目標：objective, purpose, intent, concern, in order to, 得到目標 ServeMorePassengers New

32、TracksAdded MinimizeDevelopmentCosts MinimizeDistanceBetweenTrains SafeTransportation ,目標識別,建立目標之間的量化關聯(lián) Contributes(+), ControbutesStrongly(+), Conflicts(-), ConflictsStrongly(-) 確定目標的分類 Maintain, Avoid: always目標， (PQ), (PQ)，表示總是（不）成立 Achieve, Cease: eventually目標， PQ， PQ，表示將來每個時刻（不）成立,目標模型,what,what

33、,將目標形式化,識別對象和關聯(lián),SpeedLimit,增加屬性,Speed,增加屬性,識別對象和關聯(lián),Loc, WCS-Dist,增加屬性,增加關聯(lián) following,目標模型,why,WHY目標抽象,目標模型,how,HOW目標精化,識別主體和職責分配,識別主體和職責分配,導出主體接口,Speed/AccelerationControlSystem （判斷目標前提，建立目標結論） 監(jiān)測變量：T 控制變量：CommandMessage.Accel, CommandMessage.Speed,導出系統(tǒng)操作,MaintainSafeCommandMessage,將目標操作化,構

34、建目標模型的啟發(fā)式,抽取初步的需求,H1：分析當前系統(tǒng)的目的和問題 企業(yè)的策略目的、業(yè)務目標、政策（高層目標） 運送更多的旅客、減少運營開銷 領域固有的目標 圖書的準確分類 當前系統(tǒng)的問題（需要避免、減少、減輕） 當前系統(tǒng)只允許圖書館開門時查詢館藏，導出目標“允許任何時候、任何地方查詢館藏”,抽取初步的需求,H2：在抽取文檔中搜索目標相關的關鍵詞 規(guī)定的：shall, should, must, has to, to be, may never, may not, should never, should not, 想要的：in order to, so as to, so that, obj

35、ective, aim, purpose, achieve, maintain, avoid, ensure, guarantee, want, wish, motivate, expected to, 需要改進的：improve, increase, decrease, reduce, enhance, enable, support, provide, make, ,抽取初步的目標,H3：實例化目標分類 遵循某個目標分類層次，按照不同目標類型的含義捕獲目標,在目標精化過程中識別目標,H4：問 HOW 和 WHY 的問題 通過 HOW 問題進行目標精化 通過 WHY 問題進行目標抽象,在目標

36、精化過程中識別目標,H5：分離職責 幫助將細粒度的目標分配給指定的軟件 Agent，或者定義出對環(huán)境 Agent 的期望,在目標精化過程中識別目標,H6：分析可選精化的前提和后置條件，識別軟目標,劃定目標模型的邊界,H7：精化目標直到它被分配給單個 Agent H8：抽象目標直到達到系統(tǒng)的邊界,重用精化模式,創(chuàng)建精化模式類別 檢索可重用的精化模式 調整重用模式,一組精化模式,里程碑驅動的精化模式 典型場景引入的目標分解模式 引入門衛(wèi)條件的模式 目標分治模式 不可實現(xiàn)性驅動的精化模式 不可檢測驅動的精化模式 不可控制驅動的精化模式,應用情況,小結,面向目標的方法將“目標”看作是軟件需求的源頭和依

37、據，以目標為需求獲取的基本線索，誘導需求提供者按目標的分解、精化和抽象關系，逐步構建系統(tǒng)目標與/或樹。 目標驅動需求獲取的步驟： 獲取目標結構，確定目標所關注的對象； 初步確定系統(tǒng)的相關主體和主體能夠完成的動作； 將目標操作化為約束； 對對象和動作進行精化； 導出對象和動作為確保約束的滿足所需的加強條件； 確定主體職責分配的各種候選方案； 將動作分配給相應的責任主體。,領域工程與面向特征的領域分析,領域工程 軟件復用與領域工程 領域工程與應用工程 領域工程與復用成熟度 領域工程投資回報點,面向特征的領域分析 特征的一般性定義 特征的應用舉例 軟件的特征 面向特征領域分析的基本思想與基本途徑,1

38、03,軟件復用,需求復用,軟件復用的兩點基本思想,104,105,基本思想1,以“空間”換“時間”,106,基本思想2（基本假設）,9個月,不同軟件應用之間 存在可復用的成分,領域工程,107,軟件復用：兩種開發(fā)活動,消費,軟件的哪些成分 具有復用價值？,Development FOR reuse,Development WITH reuse,反饋,108,軟件：三種基本構成成分,通用共性成分,領域共性成分,應用特定成分,適用于所有軟件應用的構成成分,適用于特定軟件應用的構成成分,適用于一組軟件應用的構成成分,109,領域,理想情況： 軟件的可復用成分具有普適性,現(xiàn)實情況：軟件應用所針對的 問

39、題的差異性 導致 軟件的可復用成分不可能具有絕對的普適性,110,領域,一組具有相似或相近軟件需求的 應用系統(tǒng)所覆蓋的功能區(qū)域,111,領域,功能區(qū)域,應用系統(tǒng),a,b,c,d,e,1,2,3,4,5,6,7,f,112,兩種類型的領域,垂直領域,水平領域,行業(yè)領域,1.行業(yè)領域的子領域 2.貫穿多個行業(yè)領域,113,與 面向普適的復用 相比 面向領域的復用更容易成功,114,領域工程與應用工程（面向領域的軟件復用）,115,消費,Development FOR reuse,Development WITH reuse,反饋,116,117,Development WITH reuse,Dev

40、elopment WITHOUT reuse,1,2,3,應用工程,應用工程,領域工程 (Development for Reuse),領域分析,領域設計,領域實現(xiàn),領域模型,DSSA,領域構件,應用工程 (Development with Reuse),需求分析,軟件設計,構件組裝,需求模型,ASSA,應用系統(tǒng),可復用軟件資產庫,生產,消費,反饋,DSSA: Domain Specific Software Architecture ASSA: Application Specific Software Architecture,應用工程,應用工程,應用工程 (Development wit

41、hout Reuse),需求分析,軟件設計,軟件編碼,需求模型,ASSA,應用系統(tǒng),輸入,1,2,3,118,領域工程投資回報點,119,120,累積成本,領域 成員數(shù)量,應用工程 (Development WITHOUT reuse),應用工程 (Development WITH reuse),領域工程 成本,？,25,軟件復用成熟度,121,軟件復用成熟度,第一級：產品的獨立開發(fā) 不存在任何形式的復用，領域內各個軟件產品的開發(fā)相互獨立 第二級：領域無關型基礎設施的標準化 軟件中的普適性復用成分得到了系統(tǒng)的復用，但仍然不存在對領域共性的復用 第三級：軟件平臺 領域中的共性成分被封裝為一個軟件

42、平臺，領域中的軟件產品都基于此平臺進行開發(fā) 第四級：軟件產品的手工導出 領域中的可復用資產具有較強的可定制性，軟件產品的開發(fā)通過手工定制的方式進行 第五級：軟件產品的自動化導出 領域中的產品通過對領域可復用資產的自動化定制而產生,122,123,復用成熟度,領域工程,應用工程,通用共性成分的復用,產品的獨立開發(fā),領域無關型基礎設施的標準化,軟件平臺,軟件產品的手工導出,軟件產品的自動化導出,小結,124,領域工程 軟件復用與領域工程 領域工程與應用工程 領域工程與復用成熟度 領域工程投資回報點,目錄,領域工程 軟件復用與領域工程 領域工程與應用工程 領域工程與復用成熟度 領域工程投資回報點,面

43、向特征的領域分析 特征的一般性定義 特征的應用舉例 軟件的特征 面向特征領域分析的基本思想與基本途徑,125,軟件復用,需求復用,面向特征的領域分析,126,什么是特征？,本人丟失一件物品： 該物品是一輛 交通工具， 有 兩個輪子，人力驅動。 車架為 斜梁結構， 車身為 黃顏色， 略微生銹， 車把上有一個 銀色鈴鐺， ,尋物啟示,將 該物品 與 同類領域中的其它物品 區(qū)分開,將 該物品所屬的類別領域與 其它類別領域 區(qū)分開,領域共性,領域變化性,什么是特征,在一般意義下，特征 是 一個事物所展現(xiàn)出的 具有區(qū)分作用 的 特點,特征概念的一個具體應用,132,對于 軟件 這個事物而言， 它的特征

44、體現(xiàn)為什么？,133,研究者 對 軟件特征 的 定義 存在兩種不同的視角,134,第一種視角下的幾個定義 (1/2),定義1（Feature Engineering Tur99）： A set of functional and extra-functional requirements. :一個由功能性和非功能性需求構成的集合,定義2（Feature-based Software Evolution Meh02）： A group of individual requirements that describes a unit of functionality with respect to

45、 a specific point of view relative to a software development life cycle. :一組單個需求，描述了一個與軟件開發(fā)生命周期中特定視角相關的功能單元,135,第一種視角下的幾個定義 (2/2),定義3（Requirements Engineering Wie99）： A set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business requirement :一組邏輯相關的功能性需求構成的集合，它為用戶提供了一種能夠滿足特定業(yè)務需求的能力,136,第二種視角下的幾個定義 (1/2),定義4（IEEE軟件工程術語詞典 Scc90）： A software characteristic specified or implied by requireme