北京大學工程碩士軟件工程教材軟件工程串講-資料下載頁

　　

【正文】 5） 轉換時間 (1) 語義 消息可以指定幾個不同的時間 （ 例如 ， 發出時間和接受時間 ） 。 這些時間可以用在約束表達式中 。 用 戶 可 以 按 需 要 為 特 定 的 目 的 給 出 時 間 表 達 ， 如elapsedTime（ 占用時間 ） 和 startExecutionTime（ 開始執行時間 ） 。 可以在約束中使用這些表達式 ， 以給消息指派有效的具體時間約束 。 (2) 表示法 可以賦予消息一個名字 。 把時間約束寫成為一個基于消息名 字 的 表 達 式 。 例如 ， 如 果 消 息 的 名 字 是 stim ， 用()表示發送時間 ， 用 ()表達接收時間 。 可以把時間約束表示在與箭頭對齊的圖的左邊上 ，也可以通過把布爾表達式 （ 可能包括時間表達式 ） 放在括號中表示約束 。 狀態圖 狀態圖用于描述模型元素 （ 如對象 ） 的行為 。 特別是 ， 用它描述元素之狀態的可能序列和動作的可能序列 。 因對特定事件 （ 如信號和操作調用 ） 的響應 ，元素在其生命期中要經歷這樣的狀態 ， 并執行相應的動作 。 1 ) 狀態圖 (1) 語義 通過描述對 事件實例 接收的響應 ， 狀態圖描述了具有動態行為能力的實體之行為 。 通常用狀態圖描述類的行為 ， 也可以用它描述其它模型實體 （ 如用況 、 參與者 、 子系統 、 操作或方法 ） 的行為 。 (2) 表示法 狀態圖是表示狀態機的圖 。 用適當的狀態表示狀態機圖中的狀態；一般地 ， 用連接狀態的有向弧表示轉換 。 (3) 實例 簡單的電話狀態的轉換 其中： 狀態 轉換 Ringing 事件 2)狀態 (1) 語義 一個狀態是對象在其生命期內的一個條件 ， 或在對象滿足某個條件 、 進行某個動作或等待某個事件的期間內的一個交互 。 在概念上 ， 對象要在一個狀態內維持一段時間 。 在這一語義下 ， 可以對瞬時狀態建模 ， 以及對非瞬時的交互建模 。 (2) 表示法 把一個狀態表示成一個四角均為圓角的矩形 。 根據需要 ， 可以把狀態劃分成由水平線相互分隔的多個分欄： ?名稱分欄 給出狀態名 。 在同一張狀態圖里不應該出現具有相同名稱的狀態 。 如果沒有狀態名稱 ， 那么該狀態就是匿名的 。 同一張圖中的匿名狀態是各不相同的 。 ?內部轉換分欄 給出在這個狀態中對象所執行的內部動作或活動的列表 其一般格式為： 動作標號 ’ /? 動作表達式 其中：動作標號標識在該環境下要調用由動作表達式指定的動作 。 動作表達式可以使用對象范圍內的任何屬性和鏈 。 若動作表達式為空 ， 則可省略斜線分隔符 。 下面給出專用的動作標號 （ 注：它們不能用作事件名 ） ： ? entry 該標號標識在進入狀態時 ， 執行由相應的動作表達式規定的動作 （ 進入動作 ） 。 ? exit 該標號標識在退出狀態時 ， 執行由相應的動作表達式規定的動作 （ 退出動作 ） 。 ? do 該標號標識正在進行的活動 （ “ do 活動 ” ） （ 只要被建模的元素是在狀態中 ， 沒有完成由動作表達式指定的計算 ， 就執行這個活動；當動作表達式指定的計算完成時 ， 可能產生一個完成事件 ） 。 3） 事件 (1) 語義 事件是值得注意的所發生的事情 。 按照狀態圖的具體用意 ，事件是指可以引發狀態轉換的所發生的事情 。 事件可以分為： a)條件 （ 用布爾表達式描述 ） 變為真 。 不論何時 ， 只要條件變為真 ， 事件都發生 。 （ 注意：這不同于監護條件 。 無論什么時候激發具有監護條件的事件 ， 都對監護條件進行求值 。 如果求值的結果為假 ， 轉換就不發生 ， 并且事件丟失 。 ） b)一個對象對另一個對象的顯式信號的接收 ， 導致一個信號事件 。 把這樣的事件的特征標記放由它所觸發的轉換上 。 c)對操作的調用的接收 ， 導致一個調用事件 。 d)在指定事件 （ 經常是當前狀態的入口 ） 后 ， 經過了一定的時間或到了指定日期 /時間 ， 導致一個時間事件 。 (2) 表示法 ?可以按如下的格式定義信號事件或調用事件： 事件名 ‘ (?用逗號分隔的參數列表 ‘ )? 參數的格式如下： 參數名 ‘ :? 類型表達式 在類圖中 ， 在類符號上用關鍵字 signal聲明信號 。把該關鍵字放在信號名的上面 ， 把參數說明為信號的屬性 。注意 ， 信號是實例之間異步傳送的消息的規格說明 。 ?可以用關鍵詞 “ after”和計算時間量的表達式表示時間事件 ， 比如 “ after (5 秒 )”或者 ” after (從狀態 A退出后經歷了 10秒 )”。 如果沒指明時間起始點 ， 那么從進入當前狀態開始計時 。 可把其它的時間事件指定為條件 ， 比如“ when (date= 2022年 1月 1日 )”。 ?用關鍵詞 “ when”和布爾表達式表示變為真的事件 。 可以把其看作是連續測試條件 ， 直到它為真 。 4） 轉換 (1) 語義 轉換是兩個狀態之間的關系 ， 表示當一個特定事件出現時 ， 如果滿足一定的條件 ， 對象就從第一個狀態進入第二個狀態 ， 并執行一定的動作 。 對于這樣的狀態的改變 ， 稱為 “ 觸發 ” 轉換 。 轉換的觸發器就是標注在轉換上的事件 。 事件可能有參數 ， 這樣的參數可由轉換指定的動作訪問 ， 也可由與源和目標相聯系的退出和進入動作分別訪問 。 在狀態圖中 ， 每次處理一個事件 。 如果事件沒有觸發任何轉換 ， 就丟棄它 。 如果在同一個簡單狀態圖中觸發了多個轉換 ， 就只對優先級最高的那個轉換點火 。 如果這些相沖突的轉換具有相同的優先級 ， 就隨機地選擇一個轉換 ， 進行觸發 。 (2) 表示法 把轉換表示成從源狀態出發并在目標狀態上終止的帶箭頭的實線 。 它可以由轉換串標記 。 轉換串的格式為： 事件特征標記 ‘ [?監護條件 ’ ]? ?/? 動作表達式 其中：事件特征標記描述帶參數的事件： 事件名 ‘ (?由逗號分隔的參數表 ‘ )? 監護條件：是布爾表達式 ， 根據觸發事件的參數和擁有這個狀態機的對象的屬性和鏈來書寫這樣的布爾表達式 。 也可用監護條件顯式地指定某個可達對象的狀態 （ 例如 ， ” in State1”或 ” not in State2”） 。 如果觸發了轉換 ， 就執行動作表達式 。 可以根據對象的屬性 、 操作和鏈以及觸發事件的參數 ， 或在其范圍內的其它特征書寫動作表達式 。 動作表達式可以是由一些有區別的動作組成的動作序列 ，其中包括顯式地產生事件的動作 ， 如發送信號或調用操作 。 表達式的細節與為模型選擇的動作語言有關 。 RUP Rational統一過程是由統一建模語言 （ Unified Modeling Languang， 簡稱 UML） 的開發者們提出來的 ， 并為對象管理組織 (Object Management Group， 簡稱 OMG )所推薦 。 RUP是在權衡了三十年的軟件開發實踐的基礎上形成的 。 例如 ， 它吸取了數百個用戶多年的現場經驗以及Ratioanal公司多年的工作成果 。 RUP對于如何運用 UML的概念進行軟件開發提供了詳細指導 。 即： ?指導開發隊伍安排其開發活動的次序 ?為各開發者和整個開發組指定任務 ?明確地規定需要開發的制品 ?提供對項目中的制品和活動進行監控與度量的準則 RUP是以用況（ use case）為驅動、以體系結構(architecture)為中心的迭代的 (iterative)、增量的(incremental)過程。具體地說： ? 以用況為驅動 用況驅動的含義是 ：以用況為單位 ， 制定計劃 、 分配任務 、 監控執行和進行測試等 。 這樣 ， 可以實現： 在產品開發的各個階段中都可以回溯到用戶的實際需求 由此可見 ， 用況將實現軟件開發的核心工作有機地組合為一體 。 ?以體系結構為中心 以系統需求 （ 用況模型 ） 為驅動 ， 緊緊圍繞 系統體系結構 ， 從不同角度描述要構造的系統的靜態和動態結構 。 其中 ， 主要涉及： 子系統 、 構件 、 接口 、 協作 、 關系和節點 等重要的模型元素的描述 。并且 ， 實現的描述應： ? 便于用戶和其他關注者的理解 ， 并達到共識； ? 便于對系統概貌的語義表述； ? 便于控制系統的開發 、 復用和演化 。 ?迭代與增量 簡單地講 ， 開發過程是將整個項目劃分為一些 “ 小 ” 的項目 ? 按核心工作流 ， 即需求規約 、 分析 、 設計 、 實現和測試這五個活動 ， 對每個小項目都進行迭代； ? 迭代被組織在 4個階段中：初始階段 、 精化階段 、 構造階段和移交階段 。 面向對象方法與結構化方法的比較 模型穩定 保持結構 平滑過渡 支持復用 易于維護 五、軟件測試技術 環境 被測對象 人員素質 被測對象模型 測試執行 正確 ? 環境模型 錯誤模型 ? 軟件測試過程所涉及的要素 ,以及 ? 這些要素之間的關系 正確 1) 測試過程模型 2）依據程序邏輯結構 白盒測試技術 （ 1）關于建立被測對象模型 控制流程圖 :結點 /分支 /過程塊 /鏈 路徑 1 2 3 6 4 5 7 X5 and Y3 其中：節點 節點 節點 節點 節點 7為過程塊 節點 2為分支，節點 4為結點 例如： 以下為一個程序流程圖，其中 該例子中 有兩個判斷， 每個判斷都包含復合條件的邏輯表達式。 （ A?1） ?（ B=0） （ A=2） ?（ X?1） X=X/A X=X+1 a b c d e F T T F 其控制流程圖為： （ A?1） ? （ B=0） X=X/A （ A=2） ? （ X?1） X=X+1 T T a c b d e 結點 1 結點 2 （ 2）“ 完整測試 ” 策略 該控制流程圖有 4條不同的路徑。 4條路徑可表示為： L1（ a→c→e ）簡寫 ace 、 L2（ a→b→d ）簡寫 abd L3（ a→b→e ）簡寫 abe 、 L4（ a→c→d ）簡寫 acd ? 路徑測試（ PX）：執行所有可能的穿過程序的控制 流程路徑。 一般來說，這一測試嚴格地限制為所有可能的入口 /出 口路徑。如果遵循這一規定，則我們說達到了 100%路徑覆蓋 率。在路徑測試中，該策略是最強的，但一般是不可實現的。 針對該例子，要想實現路徑覆蓋，可選擇以下一組測試 用例（規定測試用例的設計格式為： 【 輸入的（ A， B， X）， 輸出的（ A， B， X） 】 ）。 測 試 用 例 覆蓋路徑 【 （ 2， 0， 4），（ 2， 0， 3） 】 L1 【 （ 1， 1， 1），（ 1， 1， 1） 】 L2 【 （ 1， 1， 2），（ 1， 1， 3） 】 L3 【 （ 3， 0， 3），（ 3， 0， 1） 】 L4 ? 語句測試（ P1）：至少執行程序中所有語句一次。 如果遵循這一規定，則我們說達到了 100%語句覆蓋率（ 用 C1表達）。 在該例子中，只要設計一種能通過路徑 ace的測試用例， 就覆蓋了所有的語句。所以可選擇測試用例如下： 【 （ 2， 0， 4），（ 2， 0， 3） 】 覆蓋 L1