Transcript 第九章

正規化規格

發展清楚且不模糊的軟體規
格之技術
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 1
本章目的



說明正規規格技術如何幫助您發掘系統需求中
的問題
描述使用代數方法來定義介面規格
描述使用模型式的技術來定義行為規格
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 2
本章內容



軟體程序中的正規化規格
介面規格
行為規格
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 3
正規方法



正規規格屬於是更一般化的技術集合的一部分
，這個技術集合稱為「正規方法」(formal
methods)
它們都是以數學表示式和軟體的分析為基礎
正規方法包括
•
•
•
•
正規規格
規格分析與證明
轉換式開發
程式驗證
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 4
正規方法的接受度

正規方法並沒有如預期的成為軟體開發技術的
主流
•
•
•
•
其他軟體工程技術已經成功的改善了系統的品質，因此對
正規方法的需求就減少了
市場的變更讓即時上市比軟體的品質更重要，但是正規方
法無法加快上市的時間
正規方法的範圍受限，它們不太適合用來指定和分析使用
者的介面和使用者的互動
正規方法難以擴展成大型系統
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 5
正規方法的使用



正規方法的實際應用有限
它們的主要好處是減少系統中的錯誤數量，所
以主要的應用領域通常是關鍵系統
在此一領域中使用正規方法最有可能得到經濟
效益
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 6
軟體程序中的規格制定



規格制定和設計不可避免的必須混合在一起。
架構設計在建立某個規格的結構時很重要。
正規規格是以數學符號來表示，它在詞彙、語
法和語意中有精確的定義。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 7
規格制定與設計
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 8
軟體程序中的正規規格
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 9
規格制定技術

代數方式 (Algebraic approach)
•

系統是以一些數學運算和運算之間的關係來描述
模型方式 (Model-based approach)
•
系統是以狀態模型來指定，這些模型則是以數學式的方式
來建構，例如集合和序列。操作則是定義成修改系統的狀
態
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 10
正規規格的語言
順序式
並行式
Sequential
Concurrent
Algebraic
Larch (Guttag, Horning et
Lotos (Bolognesi and
al., 1985; Guttag, Horning
Brinksma, 1987),
代數方式
Larch（Guttag
et al., 1993),等人, 1985, 1993） Lotos （Bolognesi 與
OBJ（Futatsugi等人,
1985）
Brinksma, 1987）
OBJ (Futatsugi, Goguen
et
al., 1985)
Model-based
Z (Spivey, 1992)
CSP (Hoare, 1985)
VDM (Jones, 1980)
Petri Nets (Peterson, 1981)
模型方式
Z（Spivey,
1992） 1996)
CSP （Hoare, 1985）
B (Wordsworth,
VDM（Jones, 1980）
Petri Nets （Peterson,
B（Wordsworth, 1996）
1981）
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 11
正規規格的使用




正規規格必須在軟體開發的早期階段花比較多
的時間
如此可以減少需求上的錯誤，因為它強迫必須
仔細分析需求
從這些分析中可以發現不完整和不一致，並解
決這些問題
因此，需求問題減少了就可以減少重做的次數
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 12
正規規格的開發成本
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 13
介面規格




大型系統通常會被分解成許多子系統，而且這
些子系統之間有定義完整的介面
有了子系統的介面規格可以讓不同子系統獨立
開發
介面可已定義成抽象資料型別或物件類別
以代數方式來定義正規規格尤其適用於介面規
格
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 14
子系統介面
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 15
代數式規格的結構
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 16
規格的組成

簡介部分 (Introduction)
•

描述部分 (Description)
•

非正式的描述型別上的操作
簽章部分 (Signature)
•

定義類型(型別名稱)以及宣告欲使用的其他規格
定義使用操作的介面和參數的語法
規則部分 (Axioms)
•
定義操作的語意，以規則來定義特定的行為
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 17
系統化的代數規格

系統的代數規格可以用有系統的方式來開發
•
•
•
•
•
•
定義規格結構
命名規格
選取操作
撰寫非正式的操作規格
定義語法
定義規則
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 18
規格的操作



建構操作 (Constructor operations)：建立欲指定
之型別的實體
檢查操作 (Inspection operations)：對指定的型
別之實體做評估
指定行為時必須為每一個建構操作定義檢查操
作
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 19
對串列 ADT 的操作

建構操作。建立一個某類型的串列(List)
•

檢查操作。以該類型的串列為參數並傳回某些
其他類型
•

Create、Cons 與 Tail
Head 與 Length.
Tail 可以使用更簡單的建構操作 Create 和
Cons 來定義，而不需要以 Tail 來定義 Head 和
Length。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 20
List 規格
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 21
規格中的遞迴


操作通常會以遞迴方式來定義
Tail (Cons (L, v)) = if L = Create then Create
else Cons (Tail (L), v)
•
•
•
•
•
•
Cons ([5, 7], 9) = [5, 7, 9]
Tail ([5, 7, 9]) = Tail (Cons ( [5, 7], 9)) =
Cons (Tail ([5, 7]), 9) = Cons (Tail (Cons ([5], 7)), 9) =
Cons (Cons (Tail ([5]), 7), 9) =
Cons (Cons (Tail (Cons ([], 5)), 7), 9) =
Cons (Cons ([Create], 7), 9) = Cons ([7], 9) = [7, 9]
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 22
關鍵系統中的介面規格




以管制領空中飛行器飛行情形的航管系統為例
每一段領空可以包含多架飛行器，但是為了安
全理由必須將這些發行器分隔開
此例中使用簡單的垂直距離 300m 來分隔
若飛行器被指示的位置違反分隔規則時，系統
應該警告管制員
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 23
領空物件

對管制領空物件的關鍵操作有
•
•
•
•
Enter：在受管制的領空中加入一架飛行器
Leave：從受管制的領空中移除一架飛行器
Move：將某架飛行器從某個高度移到另一個高度
Lookup：給定一個飛行器識別碼，傳回其目前的高度
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 24
基本操作



有時候必須加入額外的操作來簡化規格
其他操作也可以使用這些基本操作來定義
基本操作
•
•
•
•
Create：建立一個領空實例
Put：加入一架飛行器但不做安全檢查
In-space：判斷某架飛行器是否在此領空內
Occupied：給定一個高度，判斷這個高度的 300m 範圍內是
否有其他飛行器
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 25
管制領空的規格
規格評註



使用基本的建構操作 Create 和 Put 來指定其他
操作
使用 Create 和 Put 定義 Occupied 和 In-space，
並且用它們來檢查其他操作的定義
會動到領空的所有操作都必須檢查是否符合安
全規範
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 27
行為規格



當物件的操作沒有獨立於物件的狀態時，使用
代數規格就有點麻煩
模型式規格可以對外提供系統狀態，並且以狀
態的改變來定義操作
Z 表示法是一個發展模型式規格的成熟技術，
它結合了正式與非正式的描述，並且在表示規
格時使用圖形來強調
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 28
Z 綱要的結構
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 29
胰島素注射系統
Insulin res ervoi r
Needl e
ass embl y
Pump
Cloc k
Sensor
Controller
Alarm
Display1
Display2
Power supply
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 30
建立胰島素注射系統的模型

Z 綱要以下列幾個狀態變數來建立胰島素注射
系統模型
•
•
•
•
•
•
•

reading?
dose, cumulative_dose
r0, r1, r2
capacity
alarm!
pump!
display1!, display2!
變數名稱後的 ? 表示輸入，而 ! 則表示輸出
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 31
不變的綱要


每一個 Z 綱要都有一個不變的部分，用來定義
永遠為真的情況
對胰島素注射系統的綱要而言，下列幾個情況
永遠為真：
•
•
•
劑量(dose)必須小於或等於容量(capacity)，也就是說不能注
射比儲液筒中還多的胰島素劑量。
每一次劑量不得超過 5 個胰島素單位，而某段時間內的注
射總劑量不得超過 50 個胰島素單位。這些條件是安全的基
本條件，將在第 17 章中深入說明。
display1! 顯示的訊息指示儲液筒的狀態。
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 32
胰島素注射綱要
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 33
劑量計算




胰島素注射系統會比較目前的讀數與前兩個讀
數計算 出所需的胰島素劑量
如果血液中葡萄糖濃度增加則注射胰島素
已注射的總劑量資訊則會被記錄下來，以便安
全的檢查是否符合不變量
這個不變量必須永遠符合 – 在計量計算中不需
要重複
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 34
DOSAGE 綱要
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 35
輸出綱要



輸出綱要可建立系統的顯示與警告，以指示某
些潛在的危險情況
輸出顯示可以顯示出計算出的劑量與警告訊息
若血糖太低便會發出警告，表示使用者應該吃
東西以增加血糖指數
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 36
輸出綱要
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 37
綱要的一致性


綱要的一致性非常重要，不一致的情況會造成
系統需求的問題
INSULIN_PUMP 綱要與 DISPLAY 就不一致
•
•

display1! 會顯示有關胰島素儲液筒的警告訊息
(INSULIN_PUMP)
display1! 則會顯示血糖狀態 (DISPLAY)
在進行系統實作之前必須先解決這個問題
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 38
重點整理



以正規方法制定系統規格可以當成非正式規格
制定技術的互補方法
正規規格是非常精準、不模糊的規格，它可以
將規格中令人懷疑的部分移除
在軟體程序中使用正規方法的首要價值在於它
可以強迫在系統開發的早期階段進行系統需求
的分析，愈早修正錯誤對系統開發的影響愈小
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 39
重點整理



正規規格特別適用於關鍵系統的開發，這些系
統在安全性、可靠性以及保全性上有非常嚴格
的要求。它們也常常用來指定一些標準。
正規化規格的代數法特別適用於一些介面的指
定，這些介面被定義成一組物件類別或是抽象
資料型別。
模型式技術則可以利用數學式的建構方法（如
集合和函數）來建立系統的模型，利用這些模
型可以提供系統的狀態，並且可以簡化某些類
型的行為規格
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 40