Quality Attribute Scenarios（6）：Modifiability General Scenarios

March 24 16:30~17:56

 

昨天介紹了modifiability的含意，今天要接著介紹課本第82-83頁所提到的modifiability general scenario。如果鄉民們已經忘了quality attribute scenarios（QAS）以及general scenarios的用途是什麼，請參考「Quality Attribute Scenarios（1）：簡介」與「Quality Attribute Scenarios（4）：Availability General Scenarios」。

***

元素	可能的內容
Source	使用者、開發人員、系統管理員
Stimulus	對於功能需求或是非功能需求的新增、修改、刪除、調整
Artifact	程式碼、使用者介面、平台、環境
Environment	執行時間、編譯時間、建構時間、設定時間、實作時間
Response	找出要修改的地方；執行修改工作但不能影響既有的其他功能；測試修改結果；部屬修改結果
Response Measure	修改所影響的項目數量、所耗費的工夫與金錢；因為修改而影響到其他功能或是非功能需求的程度

有了上面這個Modifiability General Scenario Generation表格，鄉民們就可以替自己的軟體架構定義出很多個modifiability QAS。接下來請看Teddy唬爛的例子：

Quality Attribute	Source	Stimulus	Artifact	Environment	Response	Response Measure
Modifiability	開發人員	改變網站首頁的CSS設定	程式碼	實作時間	修改結果必須保證不會引起副作用（原本可以動的功能在修改之後還是要可以動）	三小時之內
Modifiability	開發人員	對信用卡付款付款功能增加一種新的信用卡類型	程式碼	實作時間	專寫新的程式碼，將其插入到原有的付款功能之中；修改結果必須保證不會引起副作用。	增加新的信用卡型態而必須動到的既有程式碼不能超過20行（換句話說，原本的設計必須遵受open closed principle）。
Modifiability	使用者	改變應用程式介面所顯示的語系	使用者介面	執行時間	修改預設語系之後不須重新啟動程式	5秒之內
Modifiability	系統管理員	調整系統允許的最大同時上線人數	環境	設定時間	開啟系統設定檔修改同時最大上線人數參數，存檔後啟動系統	30秒之內
Modifiability	系統管理員	調整系統允許的最大同時上線人數	環境	執行時間	停止系統執行，開啟系統設定檔修改同時最大上線人數參數，存檔後重新啟動系統	三分鐘之內

參考上表依樣畫葫蘆，花點時間腦力激盪一下就可以訂出很多的modifiability QAS。看到這裡鄉民們心理可能會想：開發一個系統可能會修改的原因那麼多，怎麼可能真的去逐一寫出那麼多modifiability QAS。的確是不太可能，但是對於對客戶而言某些重要的modifiability quality attributes，逐一將其列出以便提醒開發人員或是做為與客戶確認之用，也是有其價值。例如，你的系統透過connection pool連線到後端的資料庫，connection pool大小愈大，系統同一時間可以處裡的資料量也就越大。但是由於後端的資料庫是跟很多系統一起共用的，所以如果你的系統流量沒有很大的時候，也不能一開始就把connection pool設的很大，以避免影響到其他系統的效能。因此你的系統可以讓客戶自行調整參數來決定資料庫的connection pool大小。

這樣的modifiability需求客戶也看到了，雙方都沒有問題，一直到系統做出來之後客戶才發現，原來改完connection pool的設定系統必須要重新啟動，但這並不符合客戶的期待。如果乖乖依據modifiability QAS的格式，這個問題也許就會被發現。假設修改connection pool參數之後系統需要重新啟動，那麼這樣的modifiability QAS所要求的Response Measure可能需要30秒，客戶就會質疑為什麼修改connection pool參數居然要等30秒才會發生作用，無法滿足其需求。這也就是這一系列quality attribute scenarios所要表達的目的：藉由撰寫固定格式的劇情（scenario）來表達客戶或是開發團隊對於一個系統的非功能需求。

***

友藏內心獨白：雖然挺無聊的，但是多帶一種武器在身上也是有益無害。