搞笑談軟工: Quality Attribute Scenarios（1）：簡介

2012年2月1日星期三

Quality Attribute Scenarios（1）：簡介

January 31 14:42~17:06

Scrum、軟體設計與物件導向基本觀念在一月份談得差不多了，接下來換換口味，談點軟體架構的議題。關於軟體架構有一個重要的觀念，那就是「軟體架構要解決的問題，絕大部分都不是功能面需求（functional requirements）的問題，而是所謂的非功能需求（non-functional requirements）的問題」。事實上，如果功能需求是唯一的需求，那麼軟體系統是可以沒有任何的結構，一整坨像義大利麵一樣糾纏不清都沒問題（所謂的monolithic system）。但是實際上一個軟體系統除了功能需求以外，還會有所謂的非功能需求，像是modifiabiflity（容易修改）、dependability（穩定可靠）、performance（執行效率）、time-to-market（及時上市）等等。為了要兼顧這些非功能需求，於是各式各樣的系統架構因此應運而生。

現在問題來了，如果鄉民們正在設計軟體架構，要如何滿足一個系統的眾多非功能需求？學過architecture patterns的鄉民可能會說，很簡單啊，就是套用patterns就好了。在很幸運的情況下，也許剛剛好有現成的architecture patterns可以解決手邊的問題。但是很多情況是，套用了某個（或某些）patterns的確解決了若干個非功能需求，但是卻還是遺留了其他的非功能需求需求沒有被解決，此時該如何應對？舉個實際的例子，鄉民們的系統套用了plug-ins architecture，解決了extensibility（擴充性）與modifiability（修改性）這兩個主要的非功能需求，但如果這個系統是24x7全年無休的系統，像是availability（可用性）這個重要的非功能需求就沒有直接被plug-ins architecture給涵蓋。所以看起來需要有比architecture patterns還要更基本的東西來幫助開發者應付非功能需求。

***

在Software Architecture in Practice, 2nd這本書中介紹一個方法來處理上述問題，這個方法叫做Quality Attribute Scenarios（QAS），中文姑且稱之為「品質屬性劇本」。Quality attributes就是non-functional requirements，兩者是同義詞（Teddy之前有提到過作軟體的人很喜歡搞同義字，請鄉民們多包涵...XD）。

傳統上若只是用quality attributes來定義系統的非功能需求會有三個問題：

Non-operational：光是說「這個系統需要很高的可用性（availability）」只提及了availability這個quality attribute，太過於抽象且沒有定義何謂「很高的可用性」，因此這樣的quality attribute定義對於開發人員而言是「無法操作（無從下手去滿足它）」的。
Overlapping attribute concerns：在判斷或是討論一個系統品質好壞的時候，通常要先申明是用何種角度來評論才有意義。例如，系統當機這件事情，從availability、security、usability這三種quality attributes來看，各有不同的因應之道。因此，針對某個事件來討論系統品質的時候，必須要清楚說明是從哪一個quality attribute的角度來看這件事。
缺少共通語彙：不同quality attributes領域的人可能會有用不同的字彙來敘述相同的一件事情，例如搞performance的人會說events到達一個系統，搞security的人會說系統收到很多attacks，搞availability的人會說系統產生了failures，搞usability的人會說系統收到user input。這些說法其實可能指的都是同一件事，但是卻用不同的語彙。

上述前兩個問題可以用QAS來解決。在介紹QAS長什麼樣子之前，還要先說明一個觀念，假設說鄉民們的系統被要求要具備high availability，那麼當設計系統的時候就要明確定義出來，在何種情況下需要達到high availability。例如，「電腦硬體當機」系統還是要可以運作。這個「電腦硬體當機」事件在QAS的術語就叫做stimulus，總之把stimulus當成event或是某種條件（condition）來看待就好了。

接下來說明一個QAS所包含的六個元素：

Source of stimulus：產生這個stimulus的人（一個電腦系統、人類或是其他任何軟體元件）。
Stimulus：當這個stimulus到達系統的時候，系統必須加以回應。
Environment：這個stimulus發生時的系統環境狀況，例如系統可能已經過載，或是電腦剛剛開機。
Artifact：接收到這個stimulus的人。
Response：當這個stimulus到達系統（被artiface收到）的時候系統所做出的反應。
Response measure：當系統產生response（反應）的時候，該response必須是要能夠被測量的，如此一來這個用QAS所描述的非功能需求才可以被測試。

***

最後舉個例子，下圖是兩個關於robustness的QAS，圖(b)可以解讀為「在runtime的時候callee（某個被呼叫的元件）丟出一個exception，當這個exception被boundary component所收到的時候，系統必須將這個exception轉成上層元件所了解的意義（通常會丟出一個新的exception）。驗證方法為所有經過boundary component的exception其語意都必須要是上層元件所了解的意義」。

圖(c)可以解讀為「在runtime的時候callee（某個被呼叫的元件）丟出一個exception，當這個exception被application controller所收到的時候，系統必須執行狀態回復的動作，確保當例外發生之後整個系統的狀態是正確的以便系統可以繼續執行。驗證方法為檢查這個應用程式的workspace（工作區）的資料都已經被回復成正常的狀態」。