時間漩渦

(到博客來購買本書)

窩在重慶南路的金石堂，看完這本小說的，實在不好意思抄太多句子，其實後面有很多很棒的論點，很值得抄下來細細思量。

《時間漩渦》是三部曲中的最後一本，從看到第一部曲到現在，幾近四年，不過我比較建議一口氣看完三部曲啦！回憶一下，第一部曲《時間迴旋》是2008在高雄過年時，窩在誠品看完的；第二部曲《時間軸》是2011年初在新莊圖書館巧遇借回的；第三部曲《時間漩渦》是2011年底窩在金石堂看完的。

時間迴旋系列~

時間迴旋
時間軸
時間漩渦

----------

吃完早餐，她已經勇氣滿滿，可以迎戰新的一天了--面對一個終究｢什麼都不會改變｣的現實。[15]

車子裡操勞過度的冷氣哼哼叫，指責她這個偽君子，可是她實在捨不得關掉強烈的冷氣。[20]

警方很少會追蹤犯人的狀況，對警方來說，移送就等於結案了，講難聽一點就是馬桶沖過了。[22]

不過我這輩子大部分的時間都忙著在我自己和我的過去之間築一道牆，到現在還沒築起來。有些東西是被奪走了，有些東西是自己丟棄的，有些東西則是帶在身邊，直到永遠。[42]

她輕蔑地看了我一眼：｢不懂的事拜託不要隨便評論。｣[45]

2.6-PIM-3：定義靜態結構

寫給SA的UML/MDA實務手冊
----------
第2章-做好系統分析先睹為快

2.6-PIM-3：定義靜態結構

在PIM-3中，系統分析師用類別圖來表達系統內部的靜態結構；系統具備穩定且具彈性的靜態結構，才能夠順應需求變動，迅速支撐多樣化的系統UC。之後，類別圖可能經由設計師之手，進行調整，並且成為程式設計師最關切的設計圖之一。程式設計師通常會依照類別圖的內容，來編寫並組織原始程式碼。

在PIM-3的過程中，系統分析師尋找操作絕對優先於尋找屬性。因為屬性隨處可見，特別是從PIM-1蒐集而來的表單，裡頭多的是物件必須保存的屬性。而尋找操作就沒這麼直接簡單了，系統分析師必需多動腦筋才能定義出操作，所以先別管屬性了，記得優先找操作。

進行PIM-3時，系統分析師可以經由下列步驟，建立出如圖2-5的類別圖：

1.套用交易樣式，並且經過調整之後，系統分析師可以獲得初步的靜態結構。

2.分析PIM-2的狀態圖之後，系統分析師可以為類別增添屬性及操作。

3.分析PIM-1蒐集來的表單，系統分析師可以為類別增添更多的屬性。

4.經過PIM-4的循序圖，系統分析師可以為類別增添更多的操作，並且描述操作之方法。


圖2-5:類別圖

2.5-PIM-2：分析企業規則

寫給SA的UML/MDA實務手冊
----------
第2章-做好系統分析先睹為快

2.5-PIM-2：分析企業規則

企業透過一組規則(Business Rules)來控制整體的運作，包括人員、流程、系統、概念的運作，皆受制於企業規則。由此足見企業規則之重要，所以早從PIM-1的系統UC敘述，一直到此處的PIM-2狀態圖以及稍後的PIM-3類別圖，我們都會要求系統分析師必需透過這些UML圖，記錄且呈現重要的企業規則。


圖2-4: 定期定額申購物件之狀態圖

譬如，在經過PIM-1的步驟之後，我們認為「定期定額申購」是很重要的企業物件，而且涉及許多重要的企業規則，所以決定為它繪製如圖2-4的狀態圖，以便組織企業規則，同時也對定期定額申購有更深入的理解。

2.4-PIM-1：分析系統流程

寫給SA的UML/MDA實務手冊
----------
第2章-做好系統分析先睹為快

2.4-PIM-1：分析系統流程

在CIM階段，系統分析師約莫花一~二週的時間，盡快產出初步的系統UC，以便讓相關的決策人員可以從中挑選出首期開發
的系統UC，而這也就是首期的系統範圍。

隨後，專案正式進入PIM階段，也是正式進入分析階段，所以系統分析師將投入更多的時間，針對首期的系統UC詳述細部規格，做為正式需求文件的一部份，也做為企業人員與開發人員之間的溝通文件。

所以，系統分析師在PIM-1的主要工作，將針對每一個系統UC，分析其內部細節，並編寫詳盡的系統UC敘述(UC Description)。UML並未提出標準的敘述格式可供遵守，不過系統分析師可以在網路上找到許多實用的UC敘述格式，或者翻閱一些UML或UC相關書籍，也可以發現許多很有特色的UC敘述格式。

此處，我們示範編寫「網路申購單筆基金」和「網路申購定期定額基金」的系統UC敘述，如下：

2.3-CIM-3：定義系統範圍

寫給SA的UML/MDA實務手冊
----------
第2章-做好系統分析先睹為快

2.3-CIM-3：定義系統範圍

經過了CIM-1的定義企業流程，以及CIM-2的分析企業流程之後，終於進入到CIM-3這場壓軸戲了。CIM-1和CIM-2的產出文件，跟CIM-3的產出文件之間，有如下的關聯性：

1.CIM-2活動圖中的每一個行動，都可能成為CIM-3的系統UC。

2.CIM-1中的企業參與者，以及CIM-2中的行動負責人，都可能成為CIM-3的系統參與者(System Actor)。




圖2-3: 分析一般流程所定義出的系統UC

針對上述的圖2-2一般流程的活動圖，我們分析得出如圖2-3的系統UC圖，以及下述的UC簡述。

2.2-CIM-2：分析企業流程

寫給SA的UML/MDA實務手冊
----------
第2章-做好系統分析先睹為快

2.2-CIM-2：分析企業流程

經由CIM-1圈出了系統將參與的企業流程之後，針對每一個企業UC，系統分析師得開始分析它的工作流程，並且繪製活動圖(Activity Diagram)與企業人員取得共識。隨後到了CIM-3時，才能夠依此定義出系統可以協助之處，並且規劃出系統範圍。

此處，我們挑選一般的申購基金流程當示範，並繪製出如圖2-2所示的活動圖，展示了單筆申購基金的一般交易流程。


圖2-2:申購基金之一般流程的活動圖

2.1-CIM-1：定義企業流程

寫給SA的UML/MDA實務手冊
----------
第2章-做好系統分析先睹為快

使用UML如何能讓我們做好系統分析的工作呢？就讓我們透過本章的基金模擬個案，先睹為快，搶先體驗一番。

2.1-CIM-1：定義企業流程

定義及分析企業流程(Business Process)是為了盡快釐清系統範圍，以便估算開發成本及時程，可不是為了要改造企業流程，系統分析師千萬別誤解了此步驟之目的。所以，系統分析師在定義及分析企業流程時，記得挑選跟系統有關的企業流程。

CIM-1定義企業流程的產出，主要有如下的企業UC圖和簡述。請看圖2-1的企業UC圖，圖中的每一個企業UC代表一條企業流程，企業參與者則代表位於企業外但會啟動或參與企業流程者。投資人到銀行臨櫃申購基金，啟動了銀行內部的一段關於申購基金的企業流程。再者，投資人也可能臨櫃辦理贖回基金，這又引發了另一條企業流程。


圖2-1:企業UC圖

至於企業UC簡述，簡潔扼要即可，我們主要用它來記錄和區辨企業流程。

1.6.3-Profile支持客製化UML方言

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.6-UML對MDA的助益

1.6.3-Profile支持客製化UML方言

雖然UML天性中立，可是透過UML所提供的Profile機制，卻可以讓我們自創獨特的UML方言，以便應用於特定應用領域、實體平台、實作語言或實作方法上，也因此可以表達MDA的PSM設計模式。請看圖1-23，這是一簡單的EJB2的UML Profile設計，節錄自UML規格文件裡的設計圖。


圖1-23: UML Profile for EJB2

其實，UML Profile的概念不難，使用上也容易。回頭來解釋EJB2的例子，簡單來說，使用EJB2實體平台時，一定會接觸到兩項重要的概念，其一是Bean的概念，另一是Interface的概念。

在EJB2裡，最常用的Bean有Entity Bean與Session Bean，前者主要提供資料存取的服務，後者則提供流程控制的服務。由於，UML中立於任何一項特定的實體平台，所以也就沒有定義Bean這個跟EJB2實體平台有關的特殊元素。
但是，Bean的概念與UML裡的Component概念十分相近，所以透過UML的擴充機制，便能夠以UML現有的Component元素為基底，延伸出適用於EJB2實體平台的Entity Bean及Session Bean，如圖1-24所示。同理，我們以UML裡的Interface為基底，延伸出EJB2實體平台裡的Remote Interface和Home Interface，如圖1-25所示。


圖1-24: Bean延伸自Component


圖1-25: Remote和Home延伸自Interface

1.6.2-中立的模式語言

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.6-UML對MDA的助益

1.6.2-中立的模式語言

UML是統一建模語言(Unified Modeling Language)的縮寫，顧名思義，它是建構模式(Model)的專用語言，並不指定使用於任何特殊的應用領域、實體平台、實作語言或實作方法，因此UML天生就特別適合用來表達MDA的CIM和PIM模式。

UML包含一套有明確定義的小圖示，方便設計師用來繪製設計藍圖，建造軟體模式。UML 2.0最新版定義了13款圖，每種圖款適合表達一種設計觀點。請看圖1-21的例子，這是一張UML使用案例圖，非常適合用來表達PIM階段的系統功能。


圖1-21: UML的使用案例圖

再看另一款循序圖(Sequence Diagram)，則適合用來表達軟體內部物件互動的情況。請看圖1-22的例子，我們用循序圖表達了申購基金流程。


圖1-22: UML的循序圖

有了UML之後，方便設計師表達對軟體的規劃，但是UML標準文件裡頭，並不會說明該如何設計軟體。簡言之，雖然UML定義了標準的模式語言，有助於設計師使用相同的圖示元素表達軟體設計，但是UML沒有規範也沒說明該如何設計軟體，因此我們還得熟知分析設計技術，才能夠建構出高品質的UML模式。

1.6.1-中立機構負責維護UML

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.6-UML對MDA的助益

1.6.1-中立機構負責維護UML

由於，UML非私人企業所擁有，它是OMG(Object Management Group)的公開標準，歡迎公眾使用。因此，許多專家學者喜歡自行開發工具來支援UML，很多工具都是免費的，甚至是開放源碼(Open Source)。

一旦，這些UML工具有提供Profile機制，便可以讓我們創出各式UML方言(UML based-language)，用以表達不同平台或不同領域中特殊的概念。換言之，所有這些付費、免費或開放源碼的UML工具，都是MDA的雛形工具，也都具備了成為MDA工具的基礎功能。


圖1-20: OMG的網站

請看圖1-20網頁的最上方，中間UML立體字樣的圖片是UML的商標，UML左邊第一個則是MDA的商標。UML是OMG相當重要且成功的一個標準，所以我們可以從OMG網站(http://www.omg.org/)找到UML官方網站的入口。

當然，我們也可以不透過OMG網站，直接連到UML的官方網站(http://www.uml.org/)。在UML官方網站中，列出了許多UML資源，像是UML的標準規格文件、最新消息、相關文章、開發工具或論壇網站等。

1.6-UML對MDA的助益

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML

1.6-UML對MDA的助益

UML所具備的多項特性，更使得它成為開發MDA專案不可或缺的要素之一。UML有助於發展MDA專案的幾項重要特性，包含有：

1.中立機構負責維護UML — UML是OMG的公開標準，並非私人的智財權。

2.中立的模式語言 — UML是統一建模語言(Unified Modeling Language)的縮寫，顧名思義，它是建構模式(Model)的專用語言，並不指定使用於任何特殊的應用領域、實體平台、實作語言或實作方法。

3.Profile支援客製化UML方言 — 雖然UML天性中立，可是透過UML所提供的Profile機制，卻可以讓我們自創獨特的UML方言，以便應用於特定應用領域、實體平台、實作語言或實作方法上。

1.5.4-本書所採用的分析步驟

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.5-MDA開發程序

1.5.4-本書所採用的分析步驟

依據MDA，本書所提及的步驟及產出，歸屬於CIM與PIM階段，並未涉及PSM階段。如下：

1.CIM-1：定義企業流程，產出企業UC模式。
2.CIM-2：分析企業流程，產出活動圖。
3.CIM-3：定義系統範圍，產出系統UC圖。
4.PIM-1：分析系統流程，產出系統UC敘述。
5.PIM-2：分析企業規則，產出狀態圖。
6.PIM-3：定義靜態結構，產出類別圖。
7.PIM-4：定義操作及方法，產出循序圖。

在CIM階段，系統分析師約莫花一~二週的時間，盡快產出初步的系統UC，以便讓相關的決策人員可以從中挑選出首期開發的系統UC，而這也就是首期的系統範圍。

隨後，專案正式進入PIM階段，也是正式進入分析階段，所以系統分析師將投入更多的時間，針對首期的系統UC詳述細部規格，做為正式需求文件的一部份，也做為企業人員與開發人員之間的溝通文件。

此外，系統分析師需多加注意，CIM階段與PIM階段的產出方式略有不同。系統分析師在結束CIM階段之後，才決定出PIM階段的系統範圍，也同時正式進入PIM階段。但是，在進入到PIM階段之後，系統分析師將所有系統UC依相關性分成數組，以組別方式產出該組系統UC涉及的PIM-1~4產出，隨後交給後續的開發人員進行設計、編碼及測試。然後，逐步產出一組一組的PIM-1~4產出，跟CIM的產出方式不同。

1.5.3-MDA在晶片設計的應用

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.5-MDA開發程序

1.5.3-MDA在晶片設計的應用

雖然MDA的應用起源於一般的商用資訊系統，可是它的魅力不斷擴大，所以其他領域的應用也急起直追；譬如在晶片設計的應用上，就是令人驚艷的後起之秀，值得我們觀摩學習之。

在晶片系統的開發上，採用了MDA開發程序之後，同樣會產出下列三階段的UML模型：

1.CIM(Computation Independent Model) — 聚焦於晶片系統環境及需求，但不涉及晶片系統內部的結構與運作細節。

2.PIM(Platform Independent Model) — 聚焦於晶片系統內部細節，但不涉及晶片系統的實體平台(Platform)。

3.PSM(Platform Specific Model) — 聚焦於晶片系統落實於特定實體平台的細節。例如，Java、C/C++、SystemC、Verilog等等都是一種實體平台。

隨後，軟硬體工程師會依據PSM的UML模型內容，按圖施工，編寫出適用於特定實體平台的程式碼，或者透過支援MDA的開發工具，自動產出諸如Java、C/C++、SystemC、Verilog等等軟硬整合的程式碼或電路圖。

接著，我們來看一、兩項比較有名的應用。首先，我們來看法國國立資訊與自動化研究所(INRIA)在一份2004年的“MDA for SoC Design, UML to SystemC Experiment”研究報告中，提到他們在開發ISP(Intensive Signal Processing)專案時，不僅採用了MDA技術，他們還進一步提出一個Y型方法來搭配運作，如圖1-18所示。


圖1-18: Y型方法

而且，這個團隊還開發了一個可以轉換PSM模型的軟體，若您有興趣深入研究，可到ModelTransf網站(http://www.lifl.fr/west/mdaTransf)下載相關資料，以及這個模型轉換工具的原始程式碼。

最後，我們來看業界的另一項應用實例。在2006年召開的“UML for SoC Design Workshop”會議上，意法半導體公司在“A SoC design flow based on UML 2.0 and SystemC”的報告中，提到他們成功地擴充了 EA(Enterprise Architect)這套UML開發工具，使得能夠從UML模型自動產出SystemC程式碼，達成MDA中PSM模型自動轉出程式碼的部份，如圖1-19所示。


圖1-19: UML自動產出SystemC

1.5.2-MDA的開發程序

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.5-MDA開發程序

1.5.2-MDA的開發程序

MDA專案開發的第一步驟，從CIM開始。不同於PIM與PSM，CIM試圖表達資訊系統的應用環境，而非資訊系統本身。以銀行的基金系統為例，CIM表達的對象是銀行的基金業務及組織運作，而PIM與PSM則表達支援銀行基金業務的資訊系統。

開發團隊在進行CIM時，關切的是與企業相關的營運目標、實體要件及運作流程等，先了解資訊系統的應用環境，才有可能為企業量身打造出完善的資訊系統。

在經歷建構CIM的過程中，開發團隊除了可以逐步了解企業，同時也建立出與企業人員之間的溝通方式及默契，還讓企業人員可以參與資訊系統的開發。這就好比在進行室內裝潢之前，好的室內設計師會與業主溝通，充分了解業主的期望，以及家中成員的目前狀況與未來展望，甚至邀請業主一塊參與設計，如此才能夠量身訂做出妥貼的室內空間。

至於，PIM與PSM之間的界線，比較容易混淆，兩者所關切主體都是資訊系統，分野的界線在於「平台」(Platform)一詞。PIM重視資訊系統裡重要的運作與結構，CIM旨在記錄企業領域裡的重要需求與概念，兩者之間的界線十分清楚。以平台作為PIM與PSM兩者的分野，PIM表達的設計必須無關乎或獨立於任何一個特定的平台，但是PSM恰好相反，它必須要能夠真正落實及適合某一個特定的平台。

其實，平台的概念可以再進一步細分為抽象平台(Abstract Platform)與實體平台(Concrete Platform)。一般而言，PIM可以建構於抽象平台上，但絕對不可以建構於實體平台上，只有PSM則才可以建構於實體平台上。如果沒有特別區分兩者，通常指的是實體平台，像是前述的平台以及MDA所指稱的平台，都是歸類為實體平台。

開發MDA專案時，開發團隊通常會先以CIM與抽象平台為資訊來源，匯整設計出PIM。隨後，才以PIM與實體平台為資訊來源，匯整設計出PSM。CIM、PIM、PSM與平台之間的關連，如圖1-15所示。


圖1-15:從CIM經PIM到PSM

簡言之，PIM與PSM的界線在於是否支援特定的實體平台，前者與實體平台無關，後者則得適合於某一個特定的實體平台。如此一來，PIM階段所產出的UML模式便可以由日後不同的實體平台所支援，也因此產出不同實體平台版本的PSM設計。

以室內設計為例，設計師先規劃出如圖1-16的設計圖，但不指定實際施工的建材與細節，所以這是一張PIM階段的室內設計圖。在這張設計圖裡的右下角有一個衣櫃組，但此處並不指定該衣櫃組的實際施工的建材及方式。假如，業主的預算不夠寬裕，可以選擇系統家具的方式來施工，若是比較講究的業主，可能會選擇手工打造。此處參考的圖1-16和圖1-17這兩張設計圖，下載自京城3D室內設計公司(http://www.3899.idv.tw/)的網站。


圖1-16:PIM階段的室內設計圖

請看圖1-17的衣櫃施工圖，詳細描述了衣櫃的規格和建材，像是衣櫃的拉門外面必須貼上胡桃木夾板，所以這是一張PSM階段的衣櫃施工圖。依據這張詳細的衣櫃施工圖，木工師傅就可以按圖施工。


圖1-17:PSM階段的衣櫃施工圖

1.5.1-MDA的主張

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.5-MDA開發程序

1.5.1-MDA的主張

如何因應企業與技術的快速變動，一直是軟體界的專家學者們傷腦筋的問題。然而，此刻OMG(Object Management Group)所提出的MDA(Model-Driven Architecture)，便是為了解決這個變動問題。

1.MDA欲解決的問題–如何因應企業與技術的快速變動？

2.MDA所用的工具–運用OMG現有的標準及技術，主要包括有：UML(Unified Modeling Language)、MOF(Meta-Object Facility) 、CWM(Common Warehouse Metamodel)、UML Profile、XMI(XML Metadata Interchange)以及CORBA。

3.MDA提出的解決方法–將企業及應用系統與實體技術平台分離，且以標準模式語言UML來表達與平台無關的PIM(Platform Independent Model)，然後再設計出適用於特定平台的PSM(Platform Specific Model)。如此一來，因為分隔且封裝了企業與技術兩方面的變動，所以降低了兩者之間的牽動。

MDA主張將設計切分成PIM和PSM，除此之外，MDA其實沒有額外提出其他的標準或技術，取而代之的是，它善用且整合而多項已經存在的標準及技術。請看圖1-14，這是MDA官方網站(http://www.omg.org/mda/)首頁上的圖片，充分呈現了MDA的期望與相關技術。


圖1-14: MDA

從圖1-14最內圈看起，MDA主要使用了UML、MOF及CWM這三項建模標準(Modeling Standard)，做為PIM及PSM的建模基礎。不過，對於一般的開發人員而言，只要熟知UML這套標準模式語言，就可以開發MDA專案了。

往外看圖1-14中的第二內圈，代表公開標準或私有的實體技術平台，有CORBA、XMI/XML、.NET、Java及Web Services等等。也就是說，MDA希望制定出各式獨特的實體平台專屬的PSM轉換規則，並且最好可以由廠商配合設計出MDA開發工具，以便能夠將中立的PIM自動轉出特定平台的PSM。

接下來再往外看到圖1-14中的第三內圈，代表跨平台的普遍性服務(Pervasive Services)，有目錄服務(Directory Services)、交易服務(Transaction Services)、安全服務(Security Services)以及分散式事件及通知服務(Distributed Event and Notification Services)。OMG計畫定義四項普遍性服務，讓任何平台上的應用程式或Client端都可以透過MDA環境，取得跨平台的服務。

至於圖1-14中的最外圍，則代表MDA可以應用在各式不同的領域環境中，諸如電子商務(E-Commerce)、電信(Telecom)、運輸(Transportation)、製造(Manufacturing)、醫療保健(HealthCare)、金融(Finance)以及太空(Space)等等的領域。

1.5-MDA開發程序

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML

1.5-MDA開發程序

本書採用MDA(Model-Driven Architecture)開發程序，做為系統分析師進行分析工作，以及產出UML模式的依據。MDA與UML同為OMG(Object Management Group)機構之標準。MDA主要將產出的UML模式，分為下列三個階段：

1.CIM(Computation Independent Model) — 聚焦於系統環境及需求，但不涉及系統內部的結構與運作細節。

2.PIM(Platform Independent Model) — 聚焦於系統內部細節，但不涉及實作系統的實體平台(Platform)。

3.PSM(Platform Specific Model) — 聚焦於系統落實於特定實體平台的細節。例如，Spring、EJB2或.NET都是一種實體平台。

最後，程式設計師會依據PSM的UML模式內容，按圖施工，編寫出適用於特定實體平台的程式碼。

1.4.11-企業UC與系統UC

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.11-企業UC與系統UC

使用案例可以用來表達使用者與資訊系統(System)的互動過程，也可以用來表達顧客與企業組織(Business)的互動過程，為區分兩者，特將前者稱為「系統UC」(System Use Case)，後者稱為「企業UC」(Business Use Case)。想當然爾，參與者也跟著區分為「系統參與者」(System Actor)與「企業參與者」(Business Actor)。


圖1-13: 企業UC圖

在基金模擬個案中，有些投資人不會使用電腦，所以不可能使用網路基金系統申購基金。這些投資人會到銀行櫃檯，委託理財專員代為申購基金，其間的互動就是一項企業UC。請看圖1-13裡的申購基金(企業UC)，表達了投資人(企業參與者)為了申購基金，與銀行(企業)互動的過程。

在系統開發初期，系統分析師將定義並描述企業UC，不過不是全部的企業UC，而是日後系統會涉及到的企業UC。接著，系統分析師進一步分析每一個企業UC內部的執行活動，從中圈選出可以交給系統執行的活動，並將這些可自動化的活動定義成系統UC。

接著，這些系統UC將引導整個開發程序。通常，專案會從中挑選一批系統UC做為首次釋出(Release)的範圍，隨後系統分析師才針對這些系統UC進行深度訪談，釐清需求細節且編寫文件，遞交給其他開發人員進行後續的系統設計及編碼工作。

商業周刊::時尚王最大的敵人：紅皇后效應

(摘自商業周刊第1248期2011.10.24-10.30)

就像童話愛麗絲夢遊仙境裡，紅皇后的名言：｢在我的領地裡，你要一直拼命跑，才能保持在原地，如果你要前進，就要比現在快兩倍才行。｣這個被哈佛學者卡夫曼(Stuart Kauffman)稱為｢紅皇后效應｣，形容｢商業競爭將引發一連串組織學習的淘汰賽......，即使優勝企業跑得夠快，建立起競爭優勢，成長速度也終將趨緩。｣的現象，也可以用來詮釋目前Zara因經濟規模擴大之後產生的困境。

商業周刊::貧窮小漁村，變身流行之都

(摘自商業周刊第1248期2011.10.24-10.30)

一個企業，如何善用所處的環境，這個環境的人事，也會怎麼的回報你。即使是貧瘠的土壤，也照樣有機會開出美麗的花朵。

商業周刊::老把戲玩徹底，也能變第一！

(摘自商業周刊第1248期2011.10.24-10.30)

秘密一：一切，全都倒過來想
設計概念的啟動，是從顧客開始

秘密二：快速，不斷追求極限
倉庫不是拿來堆東西，是要流動的

倉庫不是拿來｢堆放｣東西，而是拿來｢流動｣的。

秘密三：成功，不必面面俱到
甘付高額空運費，卻不花廣告費

因提供好產品的優先順序，遠高於服務，不必要的人力能省就省。

過去我們做決策總希望面面俱到。但，英得斯成功的邏輯卻是：｢不必面面俱到。｣

只要專心瞄準自己目標即可。

｢商業模式沒有新舊差別，只有是不是最適合，要賺什麼錢，就要有什麼能力｣台大管理學院副院長李吉仁說。

秘密四：缺陷，反而成為優勢
聽不到第一，才會永遠想拚滿分

把自己放小，反容易走出大格局。

｢這都是Common Sense(常識)吧…...，去滿足客戶。｣

就這樣，英德斯走出一條特立獨行的路，其他先行的強大對手，因為不可能毀掉既有能耐，去學習英德斯。最後，原先的堡壘，反而成為拖累。戰局，也就這樣被英德斯給｢倒｣過來了！

原來，通往成功的途徑，不只一條。現在面臨的絕境，反而是翻身最好的籌碼，只要你也願意偶爾｢倒過來｣想一想。

----------
英得斯集團，全球最大服裝零售王國Zara的母公司，位於西班牙西北的拉科魯尼亞小鎮。

商業周刊::開失敗派對，向滑鐵盧經驗致敬

(摘自商業周刊第1248期2011.10.24-10.30)

不要放棄，另一種對應態度就是接受失敗；讓失敗成為你創造下一個成功的最肥沃養分。對企業來說，面對失敗更是稀鬆平常，在選擇不放棄的同時，如何與失敗共處，關係到企業如何扭轉局勢。

如果只是單純的｢接受失敗｣，卻不思如何能在其中獲取教訓，那就幾乎和｢無視失敗｣一樣愚蠢。對企業來說，最重要的課題是如何管理它。首先，就是要有智慧，區分哪裡失敗是有益的，哪些是無益的。

防大錯，鼓勵員工指正
揪出｢無益的失敗｣以避免災難

無益的失敗，絕大多數都是在例行性作業中可被防止的失敗，例如，生產線上的產品瑕疵。

而鼓勵員工發掘潛在問題，必須要企業先塑造出｢讓員工覺得可安心的提報、承認失敗｣的文化，如果員工找出錯誤，卻因此讓他背負了｢搞砸整個計畫｣的壓力，那麼他們就會對錯誤閉口不言，最後就會讓原本可以防止的小錯誤演變成大災難。

改成見，出錯並非恥辱
歡迎｢有益的失敗｣以實現創意

除了鼓勵員工指出錯誤以避免｢無益的失敗｣，有些失敗是有益的，這些失敗大部分是在創意與研發的領域；事實上很多成功的事業，是建立在前人失敗的基礎上。

定水位，畫出容錯底線
UPS就不准拿客戶練習失敗

但是，沒有人喜歡失敗，要讓失敗的土壤孕育出成功創意的花朵，就要淡化員工失敗帶來的恥辱感。對企業決策者來說，最重要的是必須清楚告訴員工，哪些失敗是允許的，哪些失敗是不能容忍的。

商業周刊::全球第七大富豪，窮小子復仇記

(摘自商業周刊第1248期2011.10.24-10.30)

在人生之中，如果總是害怕，就會一事無成，我們應該有一種冒險精神。

危機嚇不倒人，也控制不了人，只有恐懼才會束縛你的手腳。

世界上有兩種復仇，一種叫作｢以牙還牙｣，將曾經承受的痛苦回報給當初的加害者；但還有一種復仇，叫作｢自我超越｣，將痛苦化為自我驅策的動力，證明自己才是勝利者。

----------
奧爾特加，Zara創辦人，全球第七大富豪。

商業周刊::王建民度過低潮7步驟

(摘自商業周刊第1248期2011.10.24-10.30)

第1步
確立精神：只要成功機率不是零就不放棄

第2步
接受挫折：誠實檢視自己不足之處，再困難也要堅持目標

第3步
正向態度：機會是給準備好的人，學會耐心等待

第4步
尋找激勵：把負面的聲音轉化成證明自己的動力

第5步
設立目標：不要想一蹴可幾，設定短期目標一步步達到

第6步
外部支援：家人是最好的支持力量

第7步
再創高峰：在低潮時開發自己的第二、第三武器

商業周刊::他們人生90%都失敗，為何還成功？

(摘自商業周刊第1248期2011.10.24-10.30)

對愛迪生來說，每次試驗失敗，意味著｢又少了一個可能失敗的機會，｣這種樂觀面對失敗的態度，才能讓這位發明大王即使遭遇無數次挫折，最後仍是成功者。就如他說的：｢失敗也是我所需要的，它和成功對我一樣有價值。｣

史特龍說：｢我把挫折當作催促我起床的號角。｣

這也印證十八世紀愛爾蘭詩人歌德斯密(Oliver Goldsmith)名言：｢人生最大的光榮，不在永不失敗，而在能屢仆屢起。｣

商業周刊::放棄，從來不是我的選項

(摘自商業周刊第1248期2011.10.24-10.30)

當一個人被打落谷底的時候，你要恢復的不只是他的身體，還有他的信心。

過去只靠一種球路就大殺四方，讓王建民對自己的伸卡球很｢靠勢｣，但經歷這段低潮後，他反而學會用更智慧的方式投球。換句話說，這個逆境，極可能成為未來的祝福。

度過低潮的方法，就是幫自己定下每個階段小小的目標。

商業周刊::特製競賽行事曆，設計王奪獎武器

(摘自商業周刊第1248期2011.10.24-10.30)

｢創意總是發生在邊界與邊境交會之處，｣陳彥廷說。

----------
陳彥廷，三年拿下百項設計大獎，為台灣人之冠。

商業周刊::挫折，起床的號角[郭奕伶]

(摘自商業周刊第1248期2011.10.24-10.30)

成功，與別人無關，而是在一次次的低谷中，如何征服自己。當然，征服的過程，一點都不輕鬆，有許多魔鬼在誘惑你，愛面子的魔鬼、想偷懶的魔鬼......，每一秒鐘，魔鬼們都在你耳邊細語：
｢我想要做…...。｣但是，你如果順了它，就落入圈套。

其實有另一個聲音，也在你心中盤旋：｢我應該做......。｣這是來自天使的苦口婆心，｢應該｣，代表的是，你必須拋棄苟且、永不放棄。

天使與魔鬼，哪一個是你的選擇？

人生真正的開始，往往發生在低谷。因為順境，多半讓人貪戀掌聲、往外探求。唯有低谷，才讓人內省，開始學習｢勉強自己｣。勉強什麼呢？勉強自己放下得失心、勉強自己再多堅持一點…...。

當我們把勉強自己變成一種習慣後，困境，將成為人生花朵綻放最肥沃的土壤。

學習感謝困境，就像席維斯.史特龍曾說的，把挫折當成是每天催促我們起床的號角吧！

商業周刊::短短2年，蘋果創下8大殺人事件！

(摘自商業周刊第1247期2011.10.17-10.23)

｢霓虹天鵝｣與2008年金融海嘯時被捧紅的｢黑天鵝｣(Black Swan)一詞，雖然同樣都意指極為罕見、且影響重大的事件；但不同的是，｢黑天鵝｣是出乎意料、難以預料的，而｢霓虹天鵝｣卻是閃閃發光，老早就告訴世人：｢我要來了！｣

｢人類的心智，遇上真正罕見、重要、難以預料的事時，經常顯得毫無準備，｣...｢我們的心智，和我們的市場，都沒有準備好面對霓虹天鵝的挑戰。｣

新法則一：沒有標準答案
老大重新洗牌，差異化才能勝出

新法則二：沒有中間地帶
毛利M型化，想賺錢就靠獨家技術

當遊戲規則重寫之時，即便趨勢未定，但若你擁有的是他人難以取代的價值，你就能站穩腳步，依照變化去修正，而不只是被動的隨波逐流。

新法則三：不創新成本更高
即使犯錯，也能累積經驗值

這確實迥異於過去台灣的慣性思維。因為，創新通常需要冒險，而冒險，又意味著你可能會犯錯。這對事事談到｢良率｣的台灣，幾乎是不同腦袋的思維。

我們的教育告訴我們要少犯錯，但是，在矽谷，失敗就像是戰士身上的疤痕一樣，大家會公開甚至驕傲的說，我做過些什麼...

｢失敗就像是(成功的)拼圖一樣。｣全球最成功的App遊戲憤怒鳥(Angry Birds)開發公司洛菲歐(Rovio)副總裁海傑瑞(Ville Heijari)說，若非有先前五十一款遊戲的開發經驗，告訴他們消費者不要什麼？哪個技術可以做得更好，就不會有第五十二款，也就是憤怒鳥遊戲的成功。

管理學大師彼得.杜拉克(Peter Drucker)在1985年出版的
《創新和企業家精神》裡寫著：在穩定的時代，組織必須把事情做得更好，然而在變動的時代，我們必須用不同的方法來做事。

捍衛過去的做法——也就是不創新的風險，比創新未來的風險高得多。

迎接這個新世代，｢你最重要的技能，是在腦中播放另一個電影(指想像的情節)：想像自己是一個從外觀察的人，看這整個局勢，從第三者的角色重新評估狀況。｣

商業周刊::你要轟掉自己，才能想像全新出路

(摘自商業周刊第1247期2011.10.17-10.23)

...｢霓虹天鵝｣。因為每個人都看得到它閃亮的顏色，你根本難以忽略它，但是，每個人的反應都是，｢這個問題總是會解決的，不用緊張，｣所以沒有人做任何事去改變它。

最大的挑戰是，改變你的觀點，你要想像，如果我們不了解歷史，不知道我們為何會走到今天，如果我們是全新的人，我們會怎麼做。

1.4.10-使用案例與參與者

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.4-重要的OO及UML概念

1.4.10-使用案例與參與者

使用者因為某種目的而來使用系統，這樣的一段互動(Interaction)過程，就是一項使用案例(Use Case)。而且，因為使用者在這過程中會與系統互動、參與使用案例，所以特別稱為參與者(Actor)。

採用使用案例的技術，可以引導系統分析師站在使用者的角度來描繪系統，開發出使用者合意的系統。使用者通常在意系統的What，而非系統的How。他們想要知道系統提供什麼樣服務，以及該如何與系統互動才能夠獲取這些服務，但是不需要知道系統內部的執行細節。


圖1-12: 使用案例圖

請看圖1-12，譬如在基金模擬個案中，投資人會在意網路基金系統有沒有提供申購基金的服務，如果有，那需要透過什麼樣的操作步驟才能夠網路下單申購基金。但是，投資人不會想要知道網路基金系統內部的執行細節，既然不知亦能用，那又何必知道呢！

商業周刊::走旁門左道，工作效率更驚人

(摘自商業周刊第1247期2011.10.17-10.23)

今日的績效頂尖者都在自行其是。他們避開了神聖的架構，破除了各式各樣的規定，以便達成任務。

｢駭｣不見得要從你心裡的解決方案開始。你不見得要有正確的答案，公司的做法也不見得是錯的。｢駭｣要從｢要是怎樣會如何？｣和｢我很納悶，為什麼...｣開始。

----------
書名：夠｢駭｣才能成為職場A咖
作者：比爾.詹森(Bill Jensen)、喬許.克萊恩(Josh Klein)
出版社：財信
出版日期：2011年10月15日

商業周刊::賈伯斯的精神，提醒世人怎麼活

(摘自商業周刊第1247期2011.10.17-10.23)

其實，人還是會無意識的追求一些習慣性要追求的東西，因為人都是慣性嘛！有些東西其實明明你已經夠了，但還是習慣性的繼續在追求；那有些東西其實你已經很清楚，你缺這個東西，你人生很不圓滿，但你習慣性的繼續逃避和繼續忽略。

愛別人是一種屈服，被別人愛是一種束縛，所以它來的時候你會覺得很恐懼，但又無意識的一直去追求它，這種行為最後背後都是補償性的，它不是真實的；那補償的東西是什麼，是缺乏自我價值感，簡單說就是不懂得愛自己啦！

商業周刊::學會做不喜歡的事[何飛鵬]

(摘自商業周刊第1247期2011.10.17-10.23)

興趣從摸索中得到，從學做不喜歡的事開始。

在工作中，人會用身心去體會，會對這份工作的內容有所感受：接觸、習慣、接受、喜歡，這是一個人尋找興趣的過程。在工作中，如果能循序漸進完成這四步驟，代表我們就找到了興趣。

當然也可能在接觸之後，對這個工作是不習慣、不接受，這代表這不是你喜歡的工作，因此你必須轉換工作，持續探索。

這種不斷探索的過程，就是一個人從不喜歡到喜歡的過程，因此從學做不喜歡的事情開始，是一個人尋找真愛的過程。

許多人始終無法找到自己真正喜歡的工作，是因為始終沒有用心去工作，去體會真正的工作內容，對工作沒感覺，也就沒有喜歡與不喜歡，變成行屍走肉的工作者，這是人生最大的悲哀。

雖然大多數的時間，我都在做我喜歡的媒體工作，但也經歷了相當長的摸索過程。而在媒體工作中，也不見得每一件事、每一個部分都是我喜歡的工作，其中大部分的時間，我也在做媒體工作中的我不喜歡的事情，所以，做自己喜歡的工作是最快樂及最有成就感的事，但前提是要先學會做不喜歡的工作，也要學會接受不喜歡的工作。

知道自己的興趣，而現有的工作又與興趣無關時，該怎麼辦？努力嘗試轉換當然是標準答案，只不過在轉換不成及轉換無門時，也要現實的接受現在這個不喜歡的工作，這也是務實的做法。

要知道興趣與生涯能合一是少數人的機運，學會做不喜歡的事，是生涯的第一課。

商業周刊::給自己的畢業禮物[郭奕伶]

(摘自商業周刊第1247期2011.10.17-10.23)

｢你們的時間有限，所以不要浪費時間活在別人的生活裡。｣斯人已逝，賈伯斯的這段話，卻點出人們最真實的懼怕。

很多時候，我們躊躇不前，覺得四面楚歌，一旦細究，卻驚訝的發現，環顧四周，根本沒有人礙著我們，一切都是自己的心魔。既然沒人綁住我們的手腳，為什麼還要用負面的能量豢養一個苦痛之身？

｢所有外界的期望、所有的名聲、所有對困窘或失敗的恐懼，在面對死亡時，都消失了，只有最真實重要的東西才會留下。｣賈伯斯的這段話，也將永遠陪伴著我們，提醒我們，別因為害怕，而綁住自己，以至於失去盡情揮灑的勇氣。