搞笑談軟工: 03/01/2012

2012年3月31日星期六

2010冬遊日本關西Day5-D元興寺和其他

March 18 15:17~16:20

走完春日原始林外加若草山的行程之後，接著要去元興寺。補一張從日本國家旅遊局網站所節錄下來的地圖，上面清楚標示Teddy與Kay這幾天在奈良去過的幾個地方。根據日本國家旅遊局網站的資料，元興寺被列入奈良七大寺院，但是在15世紀和19世紀兩次遭到大火侵襲，現存的建築只有東大塔古蹟、西小塔古蹟和有極樂堂和禪室的極樂坊。Teddy和Kay出發之前沒有做好功課，還以為會看到一座很大的寺廟。

在尋找元興寺的過程中，看到元興寺郵局。

下午三點零五分找到了「史蹟元興寺塔址」，當時覺得很奇怪，說好的寺廟哩？

看到廟門。

寺內有一個小小庭院。

疑似古蹟的建築物。

感覺被民宅圍繞。剛剛看了日本國家旅遊局網站的資料，上面寫著：「寺院區域內的火災遺迹上現在已建造了民房。近年來，利用民房改建的格調高雅的商店和咖啡店逐漸增多，作爲與大寺院和古墳迥然不同的奈良的另一個側面受到了遊客們的喜愛。」嗯，沒錯，那就去逛商店街跟咖啡店吧。

商店街照片。

又看到鹿男啦，也該出現了。

找一家看起來環境還OK又不會太貴的咖啡店休息一下。

店內乾乾淨淨的，座位不多，。

只有兩位店員（應該是老闆兼店員吧）。

咖啡和甜點味道都不錯，印象中價錢不會很貴，一份好像五百日幣左右。還有，冰涼的開水正是Teddy需要的。

在店內休息了二十五分鐘左右，繼續逛街。走著走著看到一家賣麻糬的，買的人好多喔，也買一個晚上當消夜吃吧。

又看到一家賣大判燒的店，應該就是台灣的車輪餅。買一個當場嘗鮮一下。

日本人也是要曬衣服的…XD。快下午四點鐘了，走得好累先回旅館休息小睡一下。

晚上六點多先跑到近鐵奈良站附近找吃的，找來找去沒找到合適的店。七點半左右回到JR奈良站，沒想到車站一樓這裡也有好幾家看起來不錯的店可以用餐。

看起來還不錯吃，也不會太貴。

要先投錢買飯票。

上菜，越看肚子越餓。

晚上八點二十吃完晚餐之後也沒什麼事，人也累了該看的地方也都看得差不多了。今天好像有買公車一日券，就跑去搭2號市內循環公車繞奈良市區一圈，大概二十分鐘就繞完了。

回到溫暖的Super Hotel。

打開下午買的麻糬。

大咬一口，紅豆內餡好多。

時間差不多，休息一下準備就寢，明天要到京都補玩2009年那一次京都之旅沒有玩到的地方。

***

友藏內心獨白：再會，奈良。

2012年3月30日星期五

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加減學一下還是有用滴。

***

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

2012年3月29日星期四

Quality Attribute Scenarios（7）：Performance

March 26 09:00~10:38

今天介紹課本82-84頁提到的performance（效能）的內涵。在談到軟體的非功能需求時，performance也是一個經常被提起的因素。評估一個系統的效能牽扯到三個因素：

Event：事件發生所以系統做了一些事情回應該事件。事件的種類很多，包含interrupt、message、request等等。事件可能如圖一所示的來自於系統外部，或是如圖二所示的來自系統內部。
Processing resources and time：系統需使用資源與時間來處理事件。
Response：系統對於事件的反應。在正常情況之下，系統經過一段時間應該回應每一個事件的請求，但是在某些情況，例如系統負載很重的時候，系統可能會被允許只回應若干比例的事件。

圖一

圖二

如果今天是開發一個單機版的軟體，事件的來源只有一種，在這種情況之下系統的performance問題就比較容易設計。但是由於實際上很多系統（尤其是網路連線的系統）的事件來源數量（可以簡單想成使用者的數量）、事件到達的模式（arrival pattern）與事件成長的速度不容易預估，因此使得performance問題變得相當複雜。

根據書上的說法，事件到達的模式可分為三種：

Periodic：週期性的事件，這種事件在所謂的real-time系統中很常見，例如每二十微秒控制引擎的供油量。在一般的商業系統也很常見，例如每七天備份一次資料庫，或是每一分鐘檢查一次有沒有新的電子郵件。
Stochastic：根據某種機率分布所產生的事件。
Sporadic：不屬於periodic與stochastic的偶發性事件，講成白話文就是無規則可循的事件產生模式。

介紹完事件，接下來談一下系統的反應（response）。根據書上的說法，系統反應可分為以下幾類：

Latency：系統回應事件所花的時間，有的人叫做response time。
Deadline：系統必須要在固定的時間內完成處理事件的工作，例如，每個網路封包必須要在二微秒之內被網路交換器處理完畢，這個二微秒就是所謂的deadline。
Throughput：系統的輸出量，例如一秒鐘之內可以處裡的資料庫交易量。
Jitter of the response：系統回應事件所花時間的變化程度（the variation in latency）。這一點也很重要，因為如果一個系統的反應時間變異量很大，那麼使用者在使用系統時可能會得到「不好的使用者經驗」。例如，平常完成一筆交易只需要三秒，但是有百分之一的比率，完成一筆相同大小的交易卻需要三分鐘。雖然「平均反應時間」可以滿足使用者的要求，但是這麼大的差異性卻不見得可以被接受。
Number of events not processed：當系統很忙的時候，允許多少數量的事件沒有被處裡。
Data lost：當系統很忙的時候，允許多少數量的資料遺失。

***

以上就是performance的內涵，講完收工。

***

友藏內心獨白：長大後才發現，架構師所想的performance和程式設計師所想的performance是不太一樣滴。

2012年3月28日星期三

這樣解釋Context還不懂就要…

March 24 21:30~23:01

假設鄉民們都知道design pattern是什麼東東，那麼對於pattern的定義應該不陌生：

A pattern is a proven solution to a recurring problem in a specific context.

翻成中文的意思就是說：一個樣式（pattern）是一個被已經被證明有用的解決方案（solution），可以用來解決在特定情境（context）之下重複出現的問題（problem）。挑出上面這個解釋裡面的粗體字，可以得到一個更簡化的解釋：

A pattern is a solution to a problem in a context.

樣式的格式有很多種寫法，但不管是那一種，一個樣式至少一定要包含Pattern Name，Solution，Problem，Context這四大部分（通常還有會Resulting Context或是Consequences）。Pattern Name，Solution，Problem這三個元素沒什麼好解釋的，一看就懂，但是Context就不太好了解。不容易解釋的問題交給Teddy就對了，請看以下例子。

Problem：肚子餓了晚餐要吃什麼？

Solution：可能的解決方案至少有以下幾種

清粥小菜
歐式自助餐
百元快炒
牛肉麵
XX豆漿
義大利麵
日本料理
韓國泡菜鍋
燒烤
夜市小吃

請問鄉民們那一個solution比較好？這樣很其實很無厘頭，為什麼？因為Teddy根本沒有提供足夠的「背景資料（context）」來讓鄉民們回答這個問題啊。對了，少了「背景資料」光是知道問題本身是無法從眾多可能的答案中挑選一個真正合適的答案。假設Teddy告訴鄉民們以下三種不同的背景資料：

連續「落屎（拉肚子）」三天
邀請國外來的友人體驗台灣風土民情
部門聚餐

知道了背景資料之後，就比較容易判斷那一個解決方案比較合適，例如：

連續「落屎（拉肚子）」三天：清粥小菜
邀請國外來的友人體驗台灣風土民情：牛肉麵或夜市小吃
部門聚餐：歐式自助餐或百元快炒

如果能夠更進一步提供更多、更詳細的背景資料，將可以助於挑選更合適的解決方案，例如：

邀請國外來的友人體驗台灣風土民情，遇到下雨：吃牛肉麵（下雨逛夜市比較不方便）
部門聚餐每人預算只有一百五十元：百元快炒

如果鄉民們仔細的研究pattern，應該會發現有一些pattern的problem幾乎相同，但是卻有著截然不同的solution。答案很簡單，就是因為這些pattern的context不同，所以雖然遇到的問題很像，但是卻需要不同的解法。如果要用一句成語來形容，可以說是「因地制宜」吧。

甚麼，這樣子還不懂。等一下，Teddy去拿根棍子先…@_@。

***

友藏內心獨白：Pattern不是那麼容易學滴。

2012年3月27日星期二

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）來表達客戶或是開發團隊對於一個系統的非功能需求。

***

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

2012年3月26日星期一

Quality Attribute Scenarios（5）：Modifiability

March 24 09:56~11:56

今天早上原本打算去爬新店的獅頭山，無奈下雨只好待在家裡。難得獲得一個空檔，翻出Software Architecture in Practice, 2nd這本書，重拾停了一個多月沒寫的QAS系列。這次輪到介紹modifiability（可修改性）的意義，下回再談modifiability general scenarios。

在談論軟體設計或是軟體架構品質屬性的時候，modifiability是經常被提到的一種品質屬性。依據字面上的解釋，modifiability指的是修改一個軟體系統的容易程度，或是參考書中的說法：「可修改性是指修改的成本（Modifiability is about the cost of change.）」。以下是書中提到兩個與修改的成本有關的議題：

可以改什麼：如果鄉民們有看過Mobile01的汽車討論區，可以發現上面有很多討論「改車」的帖子，內容包含有改換大尺寸的輪框或是輪胎、改換高級汽車音響、改排氣管、改車燈、加裝倒車雷達、增強改汽車隔音效果、加裝GPS與行車紀錄器等等。總地來講，一輛汽車可以改的東西還真是多啊，可能改到最後連它媽媽都不認得這是自己的小孩了（連原廠的人都不認得這是自家的車子…XD）。如果是軟體哩，軟體可以改的東西也很多，例如：
- 功能：軟體最常修改的東西就是軟體的功能（function）。通常是因為客戶的需求改變，或是開發團隊更加了解客戶真正的需求，因而需要修改軟體。
- 平台：軟體也可能因為執行平台（platform）的改變而需要加以修改。例如，Windows 8作業系統為了要支援ARM這種非Intel的CPU，因此就必須加以修改。或是Node.js原本只可以跑在Linux-based的作業系統，如果要在Windows上執行必須要先安裝Cygwin。為了讓Node.js可以在Windows原生環境下執行，就必須要加以修改原本的軟體。
- 環境：軟體執行的環境（environment）是指其他和自己軟體互動的系統，例如原本鄉民們的軟體只支援微軟的MS SQL資料庫，老闆或是客戶為了省成本於是要求你將後端的資料庫改成可以支援MySQL或是PostgreSQL。再舉的例子，假設鄉民們的Java程式使用com4j去存取Windows WMI的資料，有一天突然發現這個com4j在64-bit的Windows上無法很穩定的執行，因此被迫改用JACOB，此時鄉民們就必須要因為執行環境的改變而去修改自己的程式。
- 品質：這裡的品質就是指performance、reliability、security這一類的非功能需求。例如你寫了一個遊戲，在最高檔的Intel i7電腦上可以跑得很好，但是在比較慢的Intel i3電腦上玩起由遊戲來畫面便會lag。為了讓買不起i7的貧窮鄉民們也可以玩這個遊戲，因此你就要想辦法提高程式的執行效率，讓這款遊戲在Intel i3電腦上也可以跑得很順。
- 容量：例如鄉民們開發了一個網路訂車票系統，在平日這個系統運作很正常，但是到了連續假日或是農曆新年假期，系統就會被瞬間大量湧入的訂票需求給塞爆。為了提高系統的容量（capacity），鄉民們就必須去修改系統以便可以承擔更大量的同時上線人數與訂票交易量。
何時修改，由誰修改：在一般的情況下，談到modifiability鄉民們的腦中想到的大概都是由開發人員去修改程式碼，但實際上談到modifiability應該要同時考慮「何時修改」以及「由誰修改」這兩個條件。
- 何時修改：修改軟體（改變一個軟體的功能或是行為）的時間點包含以下幾種:
  - 在實作時（implementation time）藉由修改程式碼來改變系統的功能，這也是ㄧ般普羅大眾所最為熟知的修改方式。
  - 在編譯程式時（compile time）透過調整編譯條件來達成，例如使用C語言的#ifdef與#ifnedf等前置處理器條件來編譯出不同功能的軟體。
  - 在建構系統時（build time）藉由選擇不同的函式庫來改變系統的功能。例如當建構測試用的軟體版本時，軟體系統會使用含支援除錯資料以及包含輸出測試訊息的函式庫以方便測試與除錯，但是當建構正式釋出版本的軟體時，則使用不含除錯資料與去除輸出測試訊息的函式庫以增加系統執行效率。
  - 在系統設定時（confiuration time or setup time）藉由調整系統設定參數來改變系統的行為。例如，改變thread pool或是連線資料庫的connection pool大小以調整系統的performance與capacity。
  - 在執行時（execution time）藉由調整程式啟動參數或是程式啟動後修改系統參數來改變程式的行為。
- 由誰修改：修改系統功能的人也不限定一定是開發人員，也可以是使用者或是系統管理人員。

***

以上就是modifiability的內涵，看完本篇之後如果有人問鄉民如何判斷一個系統是否容易修改，鄉民們就可以大聲地回答：~~請參考搞笑談軟工第X集~~ 可由「改什麼內容」與「何時修改，由誰修改」這兩點來判斷。更具體的說，一旦鄉民們知道要修改什麼，修改的工作就必須要被設計、實作、測試、與部署。上述這些工作都需要花費時間與金錢，因此藉由評估與測量這些工作所花費的成本，便可判定每一次修改的難易度。

***

友藏內心獨白：有一陣子沒寫這麼紮實的文章了。