什麼是 REST?

REST 全名是 Representational State Transfer，中文翻譯成表現層狀態轉移。有些人還是搞不懂這個名詞在表達些什麼，主要是因為它省略了主詞，如果把主詞加進來可能比較容易懂。其實它的全名是 Resource Representational State Transfer，簡單的講就是資源在網路中以某種形式進行狀態轉移。將它分開來解釋就是:

Resoure:資源,即資料。比如:一段文字一首歌一種服務。我們可以用一個 URI(統一資源定位符)來指向它，每種資源對應一個特定的 URI。我們要取得這個資源就必需透過 URI 來存取它，因此 URI 就成為每一個資源獨一無二的地址了。

Representational:資源是一種信息實體，它可以有多種表現形式,比如用 JSON,XML,JPGE ，我們把資源具體呈現出來的形式叫做它為”表現層(Representation) 。URI 只代表資源的實體,不代表它的形式。所以有些 URI 的最後字元有 ,html 是不必要的,應該在 http 的請求header 信息中用  Accept 和  content-Type 欄位指定,這二個欄位才是對”表現層”的描述。

State Transfer:訪問一個網站,就代表客戶端和服務端一個互動的過程, ,這個互動的過程勢必涉及到資料的狀態化。互聯網通信協議HTTP協議，是一個無狀態協議。這意味著，所有的狀態都保存在服務器端。因此，如果客戶端想要操作服務器，必須通過某種手段，讓服務器端發生"狀態轉化"（State Transfer）。而這種轉化是建立在表現層之上的，所以就是"表現層狀態轉化"。狀態變化,通過 HTTP 動詞實現, 具體來說，就是HTTP協議裡面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。。如果一個架構符合 REST 原則，就稱它為 RESTfull 架構

理解了 REST 代表的意義之後,我們要注意在實作上的一些規範,以符合 REST 的風格

  

1.資源是透過 URI 來表示

2.URI 使用名詞而不是動詞

BAD

  /gerPerson

/listOrders

GOOD

• GET /products : will return the list of all products
• POST /products : will add a product to the collection

3.      使用正确的HTTP Status Code表示访问状态：HTTP/1.1: Status Code Definitions

4.    不要在 URI 中加入版本號

http://www.example.com/app/1.0/foo

　http://www.example.com/app/1.1/foo

因為不同的版本，可以理解成同一種資源的不同表現形式，所以應該採用同一個URI。版本號可以在HTTP請求頭信息的Accept字段中進行區分

Accept: vnd.example-com.foo+json; version=1.0

Accept: vnd.example-com.foo+json; version=1.1

Ref:http://www.ruanyifeng.com/blog/2011/09/restful.html

一個構思,二十四小時的堅持

昨天凌晨想到希望能在 PowerDesigner 的 RQM 裡,讓使用者可以選取某一字串並把它傳到 Clipboard 裡,VBS 在到 Clipboard 裡取出,然後建立 Glossary 或 Class

當 User 選取字串後,按右鍵點選選單上的功能,透過 SendKeys("^{c}") 可以模擬 copy 的動作,並將該字串送到 Clipboard 裡,但發現VBS 並不支援 Clipboard 物件,且執行完SendKeys("^{c}") 馬上去進行讀取動作,好像 SendKeys("^{c}") 也有問題,一定要有延遲的指令才可以,但 VBS  也無Sleep 指令

經過一整天的測試和尋找資料,終於找到解決的方法,方法如下 

‘選取字串後執行

Dim WshShell,objHTM, ClipboardText ,strClipboard

   set WshShell= CreateObject("WScript.Shell") 

   WshShell.SendKeys("^{c}")  ‘將選取的字串送到 Clipboard  

  WshShell.Run " ",0   '一定要執行,資料才會真的寫到Clipboard 裡,延遲時間,利用空字串,就不會一定執行一個程式

   '確實可以取得 Clipboard 裡的資料,因為vbs 沒支援使用 Clipboard 物件,所以利用htmlfile 來間接取得Clipboard 的資料

   Set objHTM = CreateObject("htmlfile")

  strClipboard = objHTM.ParentWindow.ClipboardData.GetData("Text")    

  ClipboardText="【"+strClipboard+"】" 

msgbox  ClipboardText

   set WshShell=Nothing

   set objHTM=Nothing

經過二十四小時馬拉松式的測試,終於找到的解法方法,真是大快人心

實穫價值分析

    實穫價值分析(earned value analysis) 於專案績效控制方面是一個很重要的工具。它將成本與時程整合為同一種貨幣的單位。根據統計,一般專案進行到 15% 時,將可準確的預估未來的績效。它的價值在於專案管控週期中可以明確知道目前的績效狀況,對變異的狀況來做管理活動與矯正措拖,更進一步的可以利用目前的績效狀況來預估未來的績效,並適時採取矯正行動,提供一個早期預警的功能。也就是說可用來衡量專案的進度,並預測其完成日期與最終的成本,以提供觀測時程與成本在專案過程中的變化。
      
所謂的實穫價值,是指已完成工作之價值。實穫價值分析是利用三個指標數字來評估並比較專案的進展,分別是:
BCWP(Budgeted Cost of Work Performed):已完成工作之預算成本。
    這就是所謂的實穫價值。對於已完成之工作而言,它為專案所獲得的價值,就是原先分配給它的預算,也就是用來完成該工作之預估成本。(沒有考慮時間只考慮完成了多少)可用來評估實際上有多少工作是已經完成的。

BCWS(Budgeted Cost of Work Scheduled):依時程工作之預算成本。
     這代表從專案開始到分析日為止,應該完成的工作,或者應該用掉的預算有多少。計算方法如下:
        BCWS=總預算X用掉之時間/專案時程

ACWP(Actual Cost of Work Performed):已完成工作之實際成本。
     代表直到分析日之前,已完成工作之實際成本或花費。
有了上述三個基本指標做母數,便可產生許多衍生指標來衡量專案的進度,以及時程與成本在專案過程中的變化。

時程變異(Schedule Variance,SV)=BCWP-BCWS(負值表示進度落後)
時程績效指標(Schedule Performance Index,SPI)=BCWP/BCWS(小於1.00 表示時程落後)
成本變異(Cost Variance,CV)=BCWP-ACWP(負值表示預算超支)
成本績效指標(Cost Performance Index,CPI)=BCWP/ACWP(小於 1.00 表示預算超支)
原始總預算(Budget At Completion,BAC)=即預日完工日之 BCWS
預估總預算(Estimate At Completion,EAC)=即累計已花費+預期直到完工之花費 公式為:   

 

預估最終成本之變異(Variance At Completion,VAC)=BAC/EAC
    上述指標,定期追蹤一段時間後,便可得到一張收穫價值圖,讓人一目了然知道專案現在的進度位置,以及過去歷史與中間的變化。

實穫價值分析的優點是簡單可行,因為它所衡量的是專案的花費或數量,這些都是已知的資料。其缺點是它的衡量單位是金錢不是時間,但往往專案同時也在)。意時間,也就是專案是否能如期完成? 所以雖然在預估專案完工成本上,一般採用的指標為成本績效標(CPI), 然而如果因為時程延宕的關係而造成專案完工成本的變動,則要將時程指標也考慮進來,而會影響時程的作業,通常是位於專案要徑(critial path)上的活動。故很多學者也將時程績效指標納入預估完工成本的計算，一般常見到的績效指標大致分成以下四種型式(Christensen；1993)

       (1) Cost Performance Index = CPI = BCWP/ACWP

(2) Schedule Performance Index = SPI = BCWP/BCWS

(3) Schedule Cost Index = SCI = SPI × CPI

       (4) Composite Index = W₁ × SPI + W₂ × CPI, where w₁+w₂=1

經由許多的實證研究說明預估完工成本所使用的績效指標若為CPI將會建立一個下限的範圍，而使用SPI × CPI將會建立一個上限範圍，而SPI × CPI所預估的完工成本會如此龐大，是因為一般的專案通常都是成本超支且進度落後。而在Composite Index，許多學者都以不同的權重組合(如0.2SPI+0.8CPI)作分析，而大多數的預估完工成本都會落在上下限之中(如圖)。

其中的權重績效指標則是考慮了要徑因素。其做法是

一. 判斷造成時程變異之作業(Activites)是否為要徑上的作業?

a.       若造成時程變異之作業非要徑上之作業:代表控週期中的作業並不影響專案預定的進度,所以此狀況下,只要以 CPI 指標為預估完工成本的績效指標就可。

b.        若造成時程變異之作業為要徑上之作業:代表管控週期中的作業可能會影響整個專案的進度,故時程績效指標是有必要納入預估完工成本的考量,所以在此狀況下使用權重績效指標(WPI)為預估完工成本的績效指標。

二.將一的 (A)、(B) 結合,以 PI 表示,得到如下的表示法:

一般預估完工成本可以寫成以下的通式,PI 可為不同的績效指標,而一般最常用的為  CPI:

，PI：performance index

只考慮成本變異的CPI有不足之處，將成本與時程變異的相對影響程度建構WPI：

WPI：weighted schedule cost performance index

故新的預估完工成本公式如下：


在考慮時程變異的同時，須先考慮要徑的問題，故將要徑因素納入，結合上述步驟一建議的兩個情況，本模式將修正為：

預估完工成本的準確度本研究將定義為：

 名詞解釋:
(1) PV(Planned Value)Cost Variance)：：預計成本；代表預計在某時間點所應花費的成本。
(2) EV(Earned Value)：實獲值；代表在某時間點實際獲得的價值。
(3) AC(Actual Cost)：實際成本；在某時間點實際花費的成本。
(4) CV(成本變異；實獲值與實際成本之差，大於0為佳。
(5) SV(Schedule Variance)：時程變異；實獲值與預計成本之差，大於0為佳。
(6) CPI(Cost Performance Index)：成本績效指標；實獲值與實際成本的比值。
(7) SPI(Schedule Performance Index)：時程績效指標；實獲值與預計成本的比值。
(8) WPI(Weighted Schedule Cost Performance Index)：權重績效指標；結合成本與時程變異相對權重的績效指  
      標。
(9) PI(Performance Index)：績效指標通式，可依情況選擇性使用績效指標。
(10) BAC(Budget at Completion)：預算總成本
(11)VAC(Variance at Completion)：完工成本差異，為預估完工成本與預算總成本之差。 
(12) EAC(Estimate at Completion)：預估完工成本，由變異狀況預測未來所需之成本。 
(13) 準確度：實際完工總成本與預估完工成本的比值。

為什麼要用 UseCase 來捕獲需求?

    Q: 使用者說他希望系統能有”新增客戶訂單”的功能，這不就是需求了嗎?為什麼還要用 UseCase 去描述需求?(兼談為什麼不要將功能列表或系統特性清單當成系統需求)

A: 假如你要去高雄，你會經過那幾個城市? 

 

最常的走法	台北、桃園、新竹、苗栗、台中、彰化、嘉義、台南、高雄。
有時的走法	台北、桃園、新竹、苗栗、台中、彰化、南投、嘉義、台南、高雄。
另一種特別的走法	台北、基隆、宜蘭、花蓮、台東、屏東、高雄。
塞車的走法	………

 

究竟您會採取那一種路徑，有時是依您的意圖;有時是依當時的情況;更多的時候是限制於某些條件。但不管怎樣，雖然有那麼多不同的路徑，但目的是相同的，都是到達高雄(註:這裡沒有討論使用那一種交通工具，因為那是How to 的問題，Use Case 只描寫 What，做些什麼的事)。看似一句簡單的陳述，往往隱藏著多種可能，如果我們在還沒探究此目的下存在的多種不同路徑，就去估算達成此目的所須的資源，有可能與最後使用的資源有極大的差異。其原因在於，去高雄雖是一個明確的目的，但却缺乏足夠的資訊來說明此目的底下的各種可能路徑；不同的路徑自然隱含不同的成本(實際生活上我們也許只須一種路徑來支援你到達目的的，但系統不同，因為是要長久且大量的應付使用者的日常作業，所以每一種可能發生的路徑我們都須要實作。)。前一陣子有一則新聞說:有一位民眾透過 GPS 導航要去某一個地方，雖然 GPS 規劃出了一條不塞車的路徑，但却是一條人煙稀少的山路，結果那位民眾因汽車沒油(資源不足)，而困在山裡，最後還要勞駕人民保母送汽油給他，才能脫離困境，顯然 GPS 沒有評估這種情形下所須的資源使用量。

 

       同樣的，“新增客戶訂單”或者”管理客戶訂單”，都是傳統上的功能列表，也是客戶很直覺提出的需求，如果我們以這樣的訊息加上一些些的瞭解來評估專案，往往會因沒有察覺在此需求底下的意圖、情況及限制條件的不同(使用者雖有以不同的方式來使用系統的自主性，但有時因為條件的不同，表面上相同的行為却已是不同的情況了)，而錯估專案成本。誤解目標與意圖的意義是我們專案失敗的主因。目標有如海平上的冰山，明確清晰;意圖則是海平面底下的冰塊。據說讓鐵達尼號沉沒的不是海平面上的冰山而是海平面底下的冰塊，船長誤判了海平面下冰塊的威力，才是造成這場世紀大悲劇的主因。客戶需求就有如浮在海面上的冰山，在此需求底下的意圖、情況及限制條件則是海平面底下的冰塊，冰山底下的，才是我們要應付的危機，不容輕估。

UseCase 是描寫使用者使用系統某一項功能可能會採用那些方式的說明(注意:這裡所指的”功能”和”功能選單”上的功能是不一樣的含義) ，每一種使用方式稱為一種情境或是一個場景，也可以說是我們前面所說的意圖、情況及限制條件。透過它可以協助我們去發掘與記錄使用者會以什麼樣不同的方式來使用系統，而系統又該以怎樣的方式來回應使用者。就如前面的例子:我們可以透過 UseCase 來分析使用者會以那幾種方式去新增客戶訂單，而您的系統又將如何針對不同的用法與條件採取相對的行動與使用者互動來協同完成工作。換包話說:「要系統能新增客戶訂單」是客戶需求，但為了完成這個客戶需求，您的系統須以好幾種不同的方法來協助使用者完成工作，這幾種方法就是不同的系統需求，我們就是透過使用案例來發掘與記錄系統需求。

    回顧一下過去您負責的專案，是不是經常被客戶抱怨，實現的系統常常與他們真正所要的有點誤差或不足以應付某些特殊情況。其原因就是沒有以比較充份的時間來探索使用者使用系統的各種可能方式，所造成的後果。傳統採用 DFD分析系統時，往往因太早使用技術性的觀點來處理客戶需求，急於解決問題，而忽略了使用者不同的意圖及各種限制因素；通過Use Case觀察系統，我們能夠將系統實現與系統目標分開，有助於瞭解最重要的部分――滿足用戶要求和期望，而不會沉浸於實現細節。必竟SA 的工作應該是找出對的事，然後再把事情做對。

    最後要再次說明的是:把使用案例的名稱看成是使用者對系統的一個”要求”或”期待”，而系統在各種未知的意圖及條件因素底下，為了滿足使用者的這個”要求”或”期待”所做的種種行為，則是透過使用案例的描述來記錄，結果是您將得到一組使用者在此”要求”下使用系統的各種可能情況的說明。UseCase 是目前發掘與記錄系統需求的好工具，協助我們以一種比較有系統有結構的方式來完成這項工作。