Quality Attribute Scenarios（8）：Performance General Scenarios

March 26 12:50~13:28

昨天介紹了performance的含意，今天要接著介紹課本第84-85頁所提到的performance general scenario。

元素	可能的內容
Source	多個獨立事件來源的其中一個，包含系統本身
Stimulus	Periodic event; sporadic event; stochastic event
Artifact	系統
Environment	正常模式，過載模式（overload mode）
Response	處理事件；改變服務等級
Response Measure	Latency、deadline、throughput、jitter、miss rate、data loss

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

Quality Attribute	Source	Stimulus	Artifact	Environment	Response	Response Measure
Performance	使用者	送出訂單	系統	正常模式	完成訂單交易	每一筆訂單的平均處理時間不可大於兩秒
Performance	使用者	送出車票訂單	系統	過載模式	完成訂單交易或失敗	每一筆訂單的平均處理時間不可大於一百二十秒，否則取消交易
Performance	網路設備	送出封包	系統	正常模式	將封包轉送到正確的目的地	每個封包必須在時為秒內處理完畢
Performance	前端軟體系統	送出交易請求	系統	正常模式	完成交易	每秒需具備處理三千筆交易的能力

Performance QAS就這麼簡單，當寫出系統的performance QAS之後，軟體架構師或是開發人員就必須要思考需要怎樣的軟硬體架構才可以滿足這些performance QAS的要求。這幾年一大堆有錢有勢的鄉民們喊著要開發雲端應用，莫不以系統能夠服務千百萬人作為自己生命的目標。在雲端計算中，performance（與scalability）就是很重要的品質屬性。而為了達成使用者或是客戶所期待的performance要求，許多新的軟體系統與架構也就應運而生或是變得流行了起來，像是MapReduce、NoSQL與支援non-blocking IO的Node.js等等。所以說，雖然開發軟體剛開始的時候最先想到的總是功能需求，但是隨著程式語言、軟體工具與元件的進步，做出功能需求已經相對而言已經不再那麼的困難，反倒是軟體系統對於各種非功能需求的要求越來越高。也就是說，軟體架構所介紹的這些QAS加減學一下還是有用滴。

***

友藏內心獨白：做軟體的人還真是命苦。