Y湯哥的自言自語

JavaScript 是一種物件導向的程式語言，但確不存在類別的概念，這跟我們以往在 Java、C++、C# 等語言上所學到的物件導向觀念有很大的不同，也是一般JavaScript 初學者所要適應與轉變的觀念。談 OOP 總離不開封裝、繼承與多型等基本觀念，而 JavaScript 在實作這三者時與Java、C++、C# 等語言也有著截然不同的作法，唯有先搞清楚 JavaScript 中原型式的物件導向觀念與作法，才能在使用 JavaScript 這門語言時游刃有餘。首先我們將透過如何在 js 中建立物件的幾種方式來展開 JavaScript  OOP 之旅。

      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 進行文章發佈。

      為了方便的使用此方法，我們必須讓這二套軟體的草稿文章存在相同的路徑，如此才能方便的使用上述方法讓我們即可利用 WLW 眾的外掛程式，又可方便文章的編輯與排版，並讓文章順利的發佈至 Blogger。下面就以 Dropbox 存放位置為例，說明如何更改這二套軟體預設的草稿文章存放位置，讓二者指向相同的位置。
首先建立草稿文章儲放地
我們先在 Dropbox 底下新增個 My Webblog Posts 的資料夾，例如: C:\Dropbox\My Webblog Posts 做為 WLW 與 OLW 將來要同步的草稿文章儲存地。
接著，修改  WLW 的草稿文章路徑
       一般 WLW 預設的草稿文章是存放在目前使用者的 【我的文件】目錄下的 My Weblog Posts 目錄下，如果要修改這個預設儲存路徑，則必須要在使用者機碼(HKEY_CURRENT_USER\Softwre\Microsoft\Windows Live\Writer) 下新增一個 PostsDirectory 字串值，並填入新的路徑即可。

最後，修改  OLW 的草稿文章路徑
     其方法如同 WLW ，OLW 的使用者機碼如下:
HKEY_CURRENT_USER\Softwre\Microsoft\OpenLiveWriter
範例:
    例如我們要在文章裡展示一段價值千萬美元的程式碼，我們就可先透過  WLW 的外掛程式 Code Snippet插入程式碼，如下圖:

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

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

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

JavaScript 基本上只是一個支援物件的語言,本身並沒有支援物件導向的封裝,繼承,多型等特色,但可以透過模擬來實作
1.如何在 JavaScript 使用自訂物件

   使用 Object 物件建立自訂物件

     實穫價值分析(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

   從整體來看一個系統,系統有分靜態結構與動態行為二大構面。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 的課程,感覺收獲最大的人竟是自己。因為在撰寫課程的過程中我體悟到更多的東西。甚至創造了一些新觀念和作法。深深覺得任何事唯有執著與執行,才能在過了一個轉彎後,看見另一片天空。選擇對的事來做,找對對的人成為你的伙伴。