Y湯哥的自言自語

      Windows Live Writer(WLW) 是大部份部落客的最愛，因為它除了讓部落客可以很容易的所見即所得的離線編輯文章之外，它還可將內容發佈至各種不同的部落客系統，如:WordPress 或是 Blogger 之中。雖說 MS 自 2012 開始已不維護，但就算如此，憑藉著方便的使用性及眾多的外掛程式 ，仍然是部落客無可取代的工具之一。

    但如果您是使用 Google 的  Blogger，可以發現從 2015 年 5 月左右開始，使用  WLW 您已無法順利連上 Blogger 進行文章發佈。這個問題主因是 Blogger 更新了其  API  服務，登入 Google 帳號必須改用 OAuth 2.0。在 WLW 已不維護更新的情況下，我們已無法使用它來發佈內容至 Blogger 上了，這造成很多部落客的困擾。還好 2015/12 微軟宣佈將WLW轉為「開放原始碼專案」，讓Live Writer成為.NET Foundation的一員，並且將 WLW 更名為 Open Live Writer（OLW），目前除了是英文版外，使用介面幾乎跟 WLW 一模一樣，最重要的是它已支援 OAuth 2.0 新的認證方式，所以如果您使用 Google 的 Blogger 就可以改用  OLW 。

    不過因 OLW 才剛開放，所以它還沒有外掛程式可以用，這在某些方面真的是很不方便。例如在 WLW 裡，如果一位工程師想在文章裡加一些或寫一些  code，一般會使用所謂的  Code Snippet 方便編輯及樣式化程式碼，但在 OLW 裡目前則不容易達成。還好 WLW 與 OLW 本一家親，這二套軟體所支援的格式完全相容，如此就給了我們一個暫時的辦法，讓我們使用 WLW 來編輯文章，然後再透過 OLW 進行文章發佈。

1.1 何謂MDA?

根據Standish Group 的調查顯示，在美國，專案失敗的因素中，有12.8%因

為使用者的資訊輸入不足，12.3%對於使用者需求及規格分析不完整，11.8%

起因於需求及規格的改變，這些近四成的失敗因素，都是在需求分析階段可以被避免及控制的，這也間接指出需求分析與管理在軟體開發的重要性。

看來SA 工作是一件繁雜又具挑戰性的工作，如能在一套有系統的方法下展開工作，應可節省不少時間與成本。MDA(Model-Driven Architecture)開發程序，講的是在開發過程將開發程序分為:

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

A:

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

   從整體來看一個系統,系統有分靜態結構與動態行為二大構面。UML 提供的所有圖型,都是為了捕捉以及描述這二個構面。從建模的實際操作面來看,一個系統通常會因軟體發展生命週期的各個階段所要捕抓和描述的重點不同,而有不同的產出,這些產出可歸類為 UseCase View,Logical View,Component View   ,Process View及Deployment View ,也就是所謂的四加一 觀點。每一個觀點可作為你製作 UML 各類圖型時思考的起點;另一方面又可作為你存放各類圖型的目錄。Rose 就拿它們來做為你建模時存放各階段所產的 UML 元素的目錄。Use Case View(使用案例觀點)一般又稱為功能觀點,通常一開始我們拿它來做為系統功能的說明,敘述使用者如何來使用系統,但它不會涉及如何建立系統的技術。雖然稱為使用案例觀點,但本目錄郤不是只能存放 Use Case Diagrams 的相關 UML 元素,他還是可以存放互動圖,活動圖,類別圖等 UML 元素,重點在於你想利用這些圖型來表達什麼樣的概念,如果是用來描述系統的功能並不涉及系統的實作技術,就該將它放在UseCase View 的觀點之下,管它是用 Use Case Diagram 或 Class Diagram 或其它圖型。類別和動作實作出系統裡的使用案例,動作以互動圖和活動圖來詳加說明:如此,在系統功能觀點和動態觀點之間的連結就會存在。用在使用案類執行方面的類別,是以類別圖和狀態圖來描述 。 

狀態圖(State machine diagram/Statechar diagram)是描述系統行為時最常見的一種技術。有助於描述某個物件橫跨幾個使用案例的行為。不過，用它來描述幾個物件間的合作行為則不適合，那是互動圖(interaction diagram)的責任。但也不要替每個類別畫出狀態圖,這種作法只是在浪費時間。只用它來顯示內含某些有趣行為的類別或比較複雜而重要的類別,此時它可以幫助我們了解發生了什麼事情。有些人特別用狀態圖來了解使用者介面與控制物件的某些行為。
互動圖(interaction diagram)是用來描述數個物件在某個使用案例中的行為。一般不會涉及特定的物件,只要點到高階流程就可以
活動圖(Activity diagram)適合用來展示數個物件在好幾個使用案例中的活動先後順序。

      今天幫公司同仁上完 SA 的課程,感覺收獲最大的人竟是自己。因為在撰寫課程的過程中我體悟到更多的東西。甚至創造了一些新觀念和作法。深深覺得任何事唯有執著與執行,才能在過了一個轉彎後,看見另一片天空。選擇對的事來做,找對對的人成為你的伙伴。