UML & Use case

　　本文重點在於UML的基本觀念介紹以及Use Case使用案例圖的說明；UML總共有多達十三種圖形，但其中最簡易且同時適合IT與非IT背景同仁學習的以Use Case莫屬，因此每位同仁其實都可以看懂甚至於自行繪製Use Case圖形。

　　我最近看了幾本UML相關書籍以及網路文章，並試著將當中Use Case的學習重點記錄下來，因此本文可以說是自己的Use Case學習筆記，在文章中我試著將這些重點再藉由自己的言語表達出來，希望能用一種很白話且簡單直接的方式，讓大家看過就能瞭解什麼是UML，並且能夠觀看並開始繪製基本的Use Case案例圖。

一）UML是什麼？

    UML是Unified Modeling Language的縮寫，直接翻譯成中文就是「統一模組化語言」，所以，從字面上我們大致可以猜出，UML是一種語言、用來建構模型、而且是一種統一的標準；但是這個名稱看起來還是太深奧了，它為什麼需要冠上Modeling動詞和Unified這樣的形容詞？而且程式語言一般都有著其取向與目的，像古老的COBOL是商業設計專用的語言、BASH SHELL常用在Linux系統程式、Javascript大量運用於前端(使用者端)網頁，那麼UML是用來作什麼的？它可以寫出什麼樣的程式？

　　實際上，UML是一種具有特殊目的與用途的圖形化語言，它的「Language語言」是由各種形狀不一代表著不同功能的圖形組合而成，「Modeling模組化」則是指將腦海構思中的系統架構透過這些圖形表示出來，「Unified統一」指的是這些UML圖形和組合方式有著統一的標準規格，不同的開發者和使用者們都能理解並看得懂。

　　所以，你知道了嗎？UML是一套描述系統架構的語言，就像大樓的建築師們有一套標準的圖形與構圖設計方法，軟體系統也有類似的作法，就是UML，它的產出是一張張不同類型及目的的圖形，可以協助軟體開發者瞭解客戶的需求、讓客戶知道軟體開發人員所架構出的系統是否符合所需、也可以讓軟體開發團隊們在溝通協調彼此所進行的系統時更為順暢，所以，我們也可以這麼說，UML是一套客戶與開發者團隊之間共用的標準語言，它的功用就是加強開發者與客戶需求以及開發團隊彼此之間的瞭解，最終目的是加快軟體開發效率。

二）UML的類型

    既然你已經知道了UML的用途，那麼，你可能也會懷疑它的產出是什麼？像PHP或ASP.NET是把程式碼放在網頁伺服器上執行嗎？還是像Ｃ一樣得經過Complier，或者甚至於跟JAVA一樣需要在一個虛擬機器的環境下才能執行？

　　其實都不是，正如在上段所提的，UML中的Modeling這個字，代表了它是一種將虛擬的軟體系統給模形化出來，讓你我都能瞭解這個系統的用途及目的，所以它是一種描述性語言，它最終的產出是一張張各式的圖表及流程圖，種類約有十三種，而我們可再將這些產出圖形依其特性再分為二大類，分別是Structure Diagram結構式圖形與Behavior Diagram行為式圖形。

• Structure Diagram結構式圖形
• Class Diagram類別圖
• Object Diagram物件圖
• Component Diagram元件圖
• Deployment Diagram佈署圖
• Package Diagram套件圖
• Composite Structure Diagram 組合結構圖
• Behavior Diagram行為式圖形
• Activity Diagram活動圖
• State Machine Diagram狀態機圖
• Sequence Diagram循序圖
• Communication Diagram 通訊圖
• Use Case Diagram時用案例圖
• Timing Diagram時序圖
• Interaction Overview Diagram 互動概觀圖

　　上述的結構圖和行為圖兩者最大的分野，在於前者描述的是系統的「靜態」的結構，例如使用元件、如何佈署等等，而後者描述的是系統內「動態」的行為，像是流程、過程、互動等。看到了UML有這麼多類型的圖表，你會不會心裏一驚後悔正準備要一探UML的領域？但其實在這些UML圖形中，經常使用的只有下面六種：

• Structure Diagram結構式圖形
• Class Diagram類別圖                　　經常使用，可表達系統的靜態結構，但是需要   物件導向分析的能力
• Component Diagram元件圖       
• Deployment Diagram佈署圖        → 經常使用，元件圖與佈署圖多用於分析IT基礎架構、軟體架構等，但是需要具備IT相關的Knowhow
• Behavior Diagram行為式圖形
• Activity Diagram活動圖       
• Sequence Diagram循序圖            　　經常使用，可用於表達系統的動態行為；活動圖類似流程圖的概念，因此很容易掌握製作方法，且適用於大部份的業務流程分析；其最大的優點則在於能夠清晰的表達過程中所參與的角色、角色之間的關係、以及各角色是如何參與)
• Use Case Diagram使用案例圖        → 經常使用，可表現該系統的對外功能是什麼；我們透過使用案例圖可表達出是什麼角色透過系統來作什麼事情，大部份都將此圖用於說明並表達使用者/系統的絕大部份需求。

而在這經常使用的四種圖形當中，使用案例圖、類別圖和循序圖這三者的重要性排名前三大。因此我們只要學習並透過這三種圖形，便可以很快的呈現資訊系統的對外功能、靜態結構和動態行為。

三）需求分析

    介紹完了UML的基本概念，那我們可以直接開始學習如何製作UML圖形了嗎？先別急，你知道為什麼需要畫這個UML圖嗎？是不是要規劃並製作一套系統？那麼又為什麼要製作這套統，應該不是沒事找事作，而是來自使用者的需求吧？而既然這是一套使用者需要的系統，那麼，我們就必須提醒自己，釐清使用者並且確切滿足使用者的需要對於手上這件正要開發的系統是一件事非常重要的事，我們千萬不可以一開始就肓目的埋頭苦幹，否則最終下場肯定是如同下方的圖形一樣：不符使用者真正需求且糾紛不斷。

重點1：瞭解使用者的需求是持續進化的

　　事實上，需求分析可能是整個系統開發過程中最困難的一個階段，它遠比我們正要學習的UML更具挑戰與不確定性，主要原因是：

1. 需求分析必須從事大量的溝通工作
2. 用戶對系統的需求經常敘述不清
3. 缺乏自動化工具支援
4. 使用者需求經常隨時間或想法而改變

　　由於上述這些因素，導致使用者需求經常在變動，使得開發者也因無可遵循而導致最終產品不符使用者真正的需求；但其實我們只要把握一個原則，就是認知到雖然使用者的想法總是在變化，但整體而言這種需求變化是呈現螺旋前進的，這樣的需求變化是一種持續進化的現象，因此我們不應對此有任何的抱怨。

　　此外，系統開發期間的使用者需求變更其實並不是壞事，說明了使用者對於自己的需求有了更進一步的瞭解，而開發人員若對此需求變動會感到不適應，反而代表了他們對於需求瞭解的進步程度不如使用者。

重點2：系統持續產生問題其實是一種良性的現象

    　　假設某系統已經上線了，出現以下三種情況，你會更喜歡那一種情況呢？

1. 使用者一直沒有提出過任何問題。
2. 使用者開始提了一些問題，但很快就沒有其它問題了。
3. 客戶一直在提問題，開發人員解決了這些問題後，新的問題又來了，如此不斷重複。

　　我們先看看A現象，這代表使用者幾乎或很少在使用這套系統，所以沒有提出什麼問題。

　　再來是B現象，有兩種可能，第一種是使用者在試用一段時間後，由於某些原因而不再使用該系統了；第二種可能，是使用者曾經提出過很多問題，但開發人員無法順利的解決這些問題，因此最終使用者乾脆不再使用了。

　　而最後的C現象可能是很多開發人員與使用者經常碰到也最討厭的現象，因為每天都會發現新的小問題或者被這些小問題所糾纏，但其實這是相當理想的良性狀況，代表了使用者持續的在使用該系統，因此問題一開始會比較多，而開發人員一開始的問題解決速度也低於問題的產生速度，但持續到後來，問題會逐漸減少直到完全消失。

重點3： UML可協助進行使用者需求分析

　　開發人員經常只看到使用者所開出的「需求規格」，並且往往僅侷限在這個層面進行各項的系統開發工作，但事實上，所謂的「需求規格」代表的是使用者一種很表面的需求要項，它其實並不是使用者的「需要」，使用者的需要是必須透過挖掘與分析而得到的，真正的需求分析是能夠「透視」這些表面的「需求規格」而挖掘出使用者的需要，而UML這個工具就可以協助進行「透視」的工作。

    那麼UML如何協助進行「透視」的工作呢？原因就在於它可以：

1. 弄清楚系統的目標和範圍
2. 找出系統的所有關鍵人物，並列出所有解決的問題
3. 分析業務，確認問題，發掘真正的問題
4. 針對問題，提出系統的特性
5. 針對特性，提出系統的用例，並細化功能需求和非功能需求

　　而UML的兩大類圖形：結構圖與行為圖就是協助上述的問題而產生的，透過這些圖形可讓開發人員更進一步的瞭解使用者業務以及業務流程，以及瞭解並挖掘使用者的需求。

重點4： 利用UML來協助使用者發掘需求

　　下圖是一種很常見的狀況，它表示了一個正在開發中的系統，隨著時間發展，使用者和開發人員對於需求瞭解程度的上升趨勢；在時間=0時，使用者對於需求是有一定認知的，所以會有該系統的需求產生，所以並不是從零開始，而開發人員對該系統的需求瞭解一開始就不如使用者。

　　隨著時間的發展，雙方對於需求的瞭解愈來愈強，但開發人員對需求的認識總是落後於使用者，這樣的現象造成整體系統的開發工作陷於被使用者牽著走的被動局面，且雙方很容易產生相互責怪的現象（使用者責怪開發人員水準太差，開發人員責怪使用者的需求變來變去）。   

　　要打破這現象，開發人員必須能夠做到如下圖的效果：比使用者更瞭解系統的需求，並引領他們挖掘真正的需求，如此，才能開發出真正符合使用者所需的系統。

　　

四）Usecase diagram使用案例圖的目的

    一般初接觸UML的系統開發人員對於使用案例圖並不習慣，甚至於沒有好感或嗤之以鼻，因為那看起來只是幾個幾何圖形配上個小人，外加少許的文字與箭頭這麼簡單的流程圖形，和系統開發者素來以功能面為出發點的系統流程圖差異甚大，使得很多人懷疑這樣的案例圖真的能改善工作嗎？使用它的真正目的到底是什麼？

對於系統開發者來說，「使用案例圖」最主要的功用是轉變思考的角度！

　　舉個例子來說，如果我們打算做個考勤系統，傳統上我們會先怎麼思考呢？我們是不是先想到要用什麼語言開發？可以使用什麼Database？需要提供那些功能？可能會使用到那些子系統？每項功能的流程和其它系統的關聯？... 你有沒有發覺我們都是從功能面為出發點來構思整個系統？

　　但是比較好的方式，應該是從人的角度來思考，什麼人會使用這個系統？然後逐一思考不同的人對系統有什麼需求。所以，首先我們可以估計到一般員工、主層主管、總機、財務等都會用這個系統：

• 對於一般員工來說，除了打卡之外，他還關心什麼？
• 高層主管使用這個系統的目的是不是想檢視大家的出勤狀況？
• 對於總機來說，她是不是需要做一些考勤的統計？
• 財務人員是不是要根據考勤情況來調整員工薪金？

有沒有發覺，透過這樣的思考方式，會讓我們更容易全面發掘系統的需求？

　　在「使用案例圖」中，人就是角色，當我們思考某系統的需求時，「使用案例圖」就給予我們啟示，告訴我們可從不同角色的角度來思考，因此，其實「使用案例圖」的最終目的是：

    Ａ）讓雙方有共通的語言：「使用案例圖」的特點主要在於：

1. 清晰扼要的描述系統行為。
2. 不涉及專業術語或技術議題。
3. 讓使用者與開發者雙方都能看得懂並確認需求目的

Ｂ）「使用案例圖」可以回答：

1. 這個系統有誰在用？
2. 這些人透過系統能夠做什麼事？

五）開始使用「使用案例圖」

    在對於UML有了基本的認識，並瞭解了「使用案例圖」的功能與目的後，下面我們可以開始來學習如何繪製「使用案例圖」了。

    Ａ）繪製原則

邱郁惠小姐是目前產業界相當知名的UML實務專家，她寫過相當多的UML相關書籍，也開過很多的訓練課程，在「SA前進UML專案現場」一書中，她提到IKEA創辦人Ingvar Kamprad常把「簡單是一種美德」這句話掛在嘴邊，Ingvar Kamprad經常訓誡大家，只有平庸的人，才會提出複雜的解決方案。

同樣的，邱小姐受其影響在UML的傳授上也是提倡極簡的風格，她認為保持簡單使用UML是一項值得讚許的美德，只有平庸的團隊，才會把UML用得既複雜又困難，因此要求開發團隊成員應使用最少量的UML概念和圖示才能減少習習與溝通成本，以加快開發的步調。

我本人也頗為讚同這種精簡的理念（當然囉，能夠少學一點何樂而不為呢？）因此，雖然UML的每種圖形都包含有數十種的圖示，在下面我將僅介紹四種圖示，實際上只要使用這四種圖示，便可應付所有的場合了。

    Ｂ）使用案例圖示介紹

1. Actor

　　此圖為大字上面君個圓圈，就像一個人形狀，英文名稱Actor，中文直接翻譯的話是演員、行動者的意思，一般在國內的UML書籍則解釋為「執行者」或「參與者」

　　當我們針對某系統的使用者進行分類後，可以整理出該系統擁有哪幾種角色，不同的角色有不同的工作責任，所以他們需要使用的系統功能也會不一樣；利用角色的觀點，給予了我們一個啟示，當我們思考某系統的需求時，可以從不同角色的角度來思考。

　　在繪製時，我們需要注意，角色這個圖形可以代表多個實際的人，而且同一個人也可以扮演多個不同的角色，因此實際應用時，我們通常會將某些職位或部門抽象為角色，但有的時候，這個角色也可能不是由人或職務扮演，而是另外一個系統，因為該系統會去與另一個系統互動，所以這種情況下，我們可將另一個系統畫為執行者。

2. Use Case

　　Use Case字面翻譯是「使用案例」，它代表的是系統的各項功能，也就是這個系統能夠作什麼事情。

　　請注意，在UML使用案例圖中的所謂Use Case，一定要能表達出"動詞+名詞"這樣的結構，例如，"觀看影片"、"查看自己的考勤記錄"、"登入系統"...等等，這樣一個動詞結合名詞的語句才能算是一個完整的Use Case情況，之後我們才可以將此Use Case連到某個會與其產生互動的角色上。

　　要檢視使用案例圖畫得是否合適，我們可以按此順序來讀這個圖：先讀出執行者的名字，然後讀出使用案例中的文字；按照這樣的讀法，我們可以得到兩個完整的句子：

1. 一般員工觀看創新TV節目
2. 一般員工推薦創新TV節目

如此才是一個完整的使用案例；另外要注意的是，一個使用案例不一定只能連到一個執行者，它也可以同時連到多個不同的執行者，這代表某個功能是被多個使用者所使用。

3. Association

 我們使用線條將角色與使用案例連接起來，代表某某執行者能夠執行什麼使用案例，因此該直線代表的是兩者之間的關聯。

    一般我們會使用三種直線：無箭頭的、指向用案例的、指向執行者這三種，而當中的箭頭代表的意義可以是下列其中一種：

1. "資料流向"：指執行者與使用案例的互動過程中資料的流向，如果箭頭指向使用案例，就說明使用者需向系統輸入資料，如果箭頭指向執行者，則說明系統輸出資料給執行者，而沒有箭頭的線條，代表沒有明確的資料流向。

例：系統B輸出資料給系統B

2. "誰啟動誰"：當箭頭由執行者指向使用案例，則表示由使用者啟動系統，這是大部份的情況；有極少的情況是由使用案例指向執行者，代表的意思是指系統導出資料到系統B（系統B為執行者）。

例：系統A啟動"從系統A導入資料"的使用案例

由於箭頭本身及方向代表了不同的意義，若沒有加上額外說明或其它文件（例如：使用案例表）的輔助，可能會增加雙方認知的麻煩，因此，有部份的UML專家建議並不一定要非要畫出箭頭，因為使用案例中已經有定義出"動詞"了，只要繪出的案例圖能夠讓人瞭解，有沒有箭頭並不是那麼重要。

4. Include & extend

　　與上述的使用於執行者和使用案例之間的"Association"不同，Include（包含）與Extend（延伸）代表的是使用案例之間的關係。

4.1 Include

　　從上圖我們可以看到，"管理預設節目"這個使用案例包含了四個子使用案例，分別是"增加",修改"刪除","瀏覽","刪除"（此四種功能在MIS有一個術語稱為CRUD：Create/Read/Update/Delete）。

　　我們把這四個案例抽離出來成為Include的子案例，好處在於它可以同時被其它的案例所使用，例如"增加","瀏覽","刪除"這三個功能可被一般員工的"點播"功能使用，所以此三個案例亦成為"點播"的子案例，我們可以畫成如下的圖表：

4.2 Extend

　　Extend有延伸、擴充之意，我們可以把它看成在某使用案例的基礎上，還能做什麼事情；箭頭的方向表示誰擴充了誰。我們先看看下方的圖表：

　　上圖表示一般員工可以在觀看創新TV節目的時候進行"推薦"或"轉寄"該節目的功能，換句話說，也就是一般員工在觀看創新TV節目的基礎上可以選擇"推薦"和"轉寄"。

4.3 Include & Extend

　　另外我們必須注意到的一個重點是，Extend和Include除了箭頭方向相反之外，它們之間有一個很大的差異是：對於Include來說，若缺少了任一個子使用案例會不完整，亦即對母案例來說，所有的include子案例都是必要的、缺一不可的，以上述Include說明中的例子"管理預設節目"來說，"增加",修改"刪除","瀏覽","刪除"這四個功能是管理節目表的必要項目，缺一不可，少了任何一個都無法達到"管理預設節目"的目的。

　　但是對於使用Extend的母案例來說，子案例並不是必要而是選擇性的，也就是說，若沒有了"推薦"或"轉寄"功能，一般員工還是能夠執行觀看創新TV，但有了的話可能會更好甚至可以增加使用者體驗。

4.4 Extend & UX

　　Include和Extend其實不難理解，相信你讀過便能馬上領會，此外，你有沒有發現到，其實Extend的設計與良好的使用者體驗有著密切的關係哦！

　　如果我們把上面的"觀看創新TV"的例子改成如下，那麼使用者體驗會變成如何？變成員工看到一部不錯的節目，他必須另外回到主畫面上，點選推薦或轉寄的按鈕，再從一串節目單中選擇剛剛想要推薦的那個節目，這樣使用者體驗是不是很差？因此一個好的案例關係設計，通常能給使用者帶來更好的使用者體驗。

六）最後

    除了上述的這四種圖，其實還有其它的圖例像是繼承（Inheritance）與系統邊界（System Boundary）等我並沒有介紹，首先，並不是所有的案例圖都需要畫出系統邊界，如果在每個使用案例圖的案例中都畫出系統邊界將會顯得很累贅，我們只要在最外層的使用案例圖畫出系統邊界就可以了。另外在繼承圖例的使用上，"繼承"這個概念對於非IT背景的同仁來說經常比較難以理解，尤其它很容易與Include及Extend造成混淆，因為那個被繼承的父使用案例，往往是一個抽象、無法被實際執行的使用案例，它必須被繼承後才能夠由使用者來執行，對於沒有軟體開發經驗和物件導向設計經驗的同仁和使用者來說，要去理解這種"抽象類別"會有些困難。

    在本文中，我大致介紹了UML及UML圖形Use Case（使用案例圖）的繪製，並以創新TV為範例示範怎麼使用其中最常用的四種圖例，相信您只要利用這四個圖例便可看懂UML並應付部份的系統開發需求了。你要試看看瞭解多少了嗎？下圖是我在網路上找到的一個網路訂書的Use Case，僅用到本文所介紹的四種基本圖例，請試看看是否能夠領略。

　　

電腦產業的生態鏈 -「浪潮之巔–剖析IT產業」

    本文內容摘自於吳軍博士所著的「浪潮之巔–剖析IT產業　掌握下一個黃金十年」一書的第四章「電腦產業的生態鏈」，這是一本內容精彩、用字洗鍊的書，吳軍用史詩般壯麗的述說方式，時間縱貫前後100多年、領域橫括IT上下游產業、涵蓋軟體及硬體等等企業及革命性產品，實在是非常值得一讀的書，我把其中精彩的第四章「電腦產業的生態鏈」的內容整理摘錄於此，並將部份心得繪製成圖表作為補充，提供給大家參考。

1. 三種定律

　　下面的三種個定律合稱為IT界三大定律，此三者提出的時間不同，但卻彼此糾葛相互影響，對於IT產業的發展循環致關重大，王軍在書中詳細的介紹了這三大定律，以及它們之間的關係與影響。

Ａ）摩爾定律Moore’s law

　　摩爾定律描述的是一種電腦等IT技術快速發展的現象，它造成的影響是IT產品新舊的汰換率快速，產品價格迅速的大幅下修；這個理論最早是由英特爾的創始人Gordon Moore在1965年所提出，他指出，積體電路的集成度每兩年會增加一倍（後來大家把這個週期縮短到18個月），若我們將積體電路的發展應用到PC產業，變成每18個月，電腦等IT產品的性能成長一倍，或者說，相同性能的電腦等IT產品，每18個月價錢便會下降一半；雖然這個發展速度頗讓人吃驚，但幾十年來IT行業的發展始終遵循著摩爾定律預測的速度在走。

　　舉例來說，1945年時候，世界上第一台電腦ENIAC的速度是在一秒鐘完成5000次定點的加減法運算，到了2007年，使用英特爾Core晶片的個人電腦計算速度是每秒500億次浮點運算，已經是ENIAC的1000萬倍，而當年度（2007年）世界最快的電腦深藍BlueGene/L它的計算速度則高達每秒鐘367萬億次，是ENIAC的734億倍，換算下來，正好是每20個月成長一倍，和摩爾定律預測的速度大致相同。

而儲存容量的增長速度比起PC速度則又更快一些，大約每15個月就成長一倍；1976年，蘋果電腦軟碟機的容量為160KB，而到了2007年目前同樣的價格下所購置的硬碟容量可到500G，是當時的的300萬倍。而網路速度呢？1994年時代家用的數據機撥接速度是2.4Kbps，到了2007年的ADSL通過同樣一條電話線的速度可以達到10Mbps的傳輸率，這樣的成長速度大約是每年成長一倍。

直到目前，IT領域的技術進步仍看不到停下來的跡象，長期而言摩爾定律依然適用，這使得IT產業有著它獨有的特性，因為在人類文明史上，沒有任何一個其它的產業像IT產業有這種類似的成長現象。

正因為摩爾定律主導著IT產業的發展，使得IT行業的公司必須著重在：

1. 產品開發時程縮短：IT公司必須在比較短的時間內完成下一代產品的開發，避免市場上不會有太多競爭者。
2. 有了技術的支援，各種應用會不斷的湧現：例如高畫質影片數位化的計算，在早期連IBM的大型機也無法勝任，但現在一台筆記本大小的Sony遊戲機便可做到了，再例如，在十年前不會有人想建立類似Youtube線上串流影音的播放的公司，但現在網路速度發展，讓Youtube成深入每個人的日常生活。
3. 針對多年後的市場預先進行研發：例如針對十年後家庭上網速度提高一千倍的場景。

個人補充：摩爾定律自1965年提出，雖然至今持續應驗了近50年，但至少在20年前，就有學者開始計算或是討論它的死亡日期，最主要的癥結在於光學顯影（Lithography）的技術障礙以及微縮高昂的成本超過了由此帶來的成本節約；而在更高的速度、更低的能耗和更低的成本三個因素中，晶片廠商僅能一次選擇其二，例如前幾年有很多人認為10奈米可能就是摩爾定律的極限（但目前已被業界認為可能實現）。
　　在網路上有人以米粒上畫圖作為例子解釋說明光學顯影的技術障礙，相當有趣，茲摘錄如下：（來源：有物報告網站）
　　光學顯影這個技術障礙有點類似要學生在米粒上畫圖。要畫出一幅很小很小的圖，有三個要素：很小的米粒、更小的筆尖、跟穩定的墨水供應。在半導體業中，米粒就是晶片，筆尖就是光波長，墨水就是光源強度。晶片（米粒）可以一直縮小，但目前的顯影技術障礙是指光無法兼具波長（筆尖）小且光源強度（墨水）穩定。目前已成功製造波長夠小的光源，但光源強度仍未達商業化的標準。而且提高光源強度（影響曝光速率）同時還必須考慮穩定度，畢竟筆寫到一半沒墨水頗麻煩的。
　　為了延續摩爾定律生命的關鍵技術，Intel 在20年前認為自己找到夠小的筆尖了—極紫外光（Extreme Ultraviolet，"EUV"，波長13.5nm），是現在光源波長的７％而已，目前已應用於Intel力力推廣的EUV 顯影技術中。

       

Ｂ）安迪-比爾定律Andy & Bill’s law

這個定律中的安迪指的是前英特爾公司CEO安迪.葛洛夫（Andy Grove），而比爾指的則是大家熟知的微軟創始人比爾.蓋茲，簡短的說這個定律就是：「比爾要拿走安迪所給的What Andy gives, Bill takes away.」。

為什麼這個定律可以說成「比爾要拿走安迪所給的」呢？我們知道在上述的摩爾定律運作之下，英特爾處理器的速度每18個月成長一倍，而電腦記憶體和硬碟容量則以更快的速度增長，但是，微軟作業系統及其它的應用軟體執行速度卻愈來愈慢，所需要的CPU資源和空間資源愈來愈多，所以，現在的電腦雖然比10年前快了100倍，但是執行軟體感覺上速度還是跟以前差不多，雖然功能有增加，但是增加的功能和其所消耗的資源與空間是不等比例的，這使得一台10年前的電腦能裝多少程式，現在的也不過裝這麼多，而最重要的，如果不更新電腦，很多新的軟體便無法使用，連上網也會成了問題，最大原因是這些新增的硬體效能都讓新的系統和應用軟體給吃掉了。

雖然使用者對於這種新軟體把硬體升級後所帶來的好處幾乎全部耗盡的現象覺得反感，但是在IT產業，上下游的硬體廠商們恰恰是靠著這種軟體開發商們用光自己提供的硬體資源而得以生存，例如在2005上半年，因為微軟的新作業系統Vista遲遲無法上市，從上游的英特爾到下游的惠普、戴爾等等PC廠商，以及Marvell和Seagate等配件廠商，因為使用者沒有更新電腦的需求，造成這些公司的股票紛紛不同程度下跌了20%~40%，直到2005年低Vista終於推出，這些公司的銷售及股價才得以反轉提升；Vista與前一版XP相比，可能多提供了20%的功能，但是它所需要的記憶體卻幾乎是原先的兩倍、CPU耗用率成長一倍，因此，除非更新電腦否則幾乎無法升級新的作業系統。

而目前的手機產業也重蹈著WinTel的情況，從PC到手機，安迪-比爾定律照樣適用！Google的Android就類似微軟的Windows，而高通、博通和Marvell這一大兩小的ARM手機晶片製造商則發揮了當年英特爾和AMD的作用，而在Android以外的其它手機OS如蘋果或Symbian等等，都是Android的兄弟（它們都是源自同一個Linux核心），而摩托羅拉、三星、HTC、Sony等等就如同當年眾多的PC製造商；2008年上市的HTC第一代Android手機G1，它的主頻只有528MHz，而到了2010年初HTC為Google製造的Nexus One超薄手機主頻就達到了1GHz，不到18個月的時間速度成長了一倍，但現在G1也已經慢到不好用了。

個人補充：安迪.比爾定律描述的是一種軟體升級推動硬體換代的現象，這是客套的解釋，說得直接點，這定律就是指「軟體就是會越來越腫」的現象，軟體每隔18個月就會腫大一倍，把硬體因摩爾定律而升級的配置都消秏光了。

　　這當中所指的軟硬體也就是之前我們常說的「WINTEL聯盟」的組合，此安迪.比爾定律已經牢不可破地運轉了超過30年，然而，自從蘋果2008年推出的3G版IPHONE及繼之而來的IPAD，開啟了一個前所未有的移動網際網路時代之後， 「WINTEL」所代表的PC市場便開始逐漸被侵蝕了，隨後ANDROID強勢的發展更讓WINTEL處於絕對劣勢，在這樣的巨變下，安迪.比爾定律似乎正如王軍在書中所提到的，主角已更換為ARM與ANDROID，繼續著軟體升級推動硬體換代的宿命。

Ｃ）反摩爾定律 Reverse Moore’s law

Google的前CEO艾瑞特.史密特（Eric Schmidt）在一次採訪中指出，如果你反過來看摩爾定律，一個IT公司如果今天和18個月前賣掉同樣數量的同產品，那麼代表它的營業額就要降一半，IT界將它稱為反摩爾定律，這個定律對於所有的IT公司來說都是相當可怕的，因為花了相同的投入，卻只得到以前一半的收入，因此反摩爾定律逼迫著所有的硬體設備公司必須趕上摩爾定律規定的更新速度，否則將會被無情的淘汰，因此所有的硬體設備製造商活得都非常的辛苦。

另外相當重要的一點，就是王軍在書中提到所謂的：反摩爾定律亦有其所謂積極的一面，即它會促成科技領域「質」的進步，並為新興公司提供生存和發展的可能；這是什麼意思呢？我們再往下看。

和所有事物的發展一樣，IT領域的技術進步也有量變和質變兩種；比如說，同一種處理器在系統結構上沒有太大變化，而只是主頻提高了，這種進步就是量變的進步，而當處理器由16位元上升到32位元，再到64位元時，這樣的變化就有了小的質變，如果那一天能用到奈米技術或生物技術，那麼就作到了質的飛躍。為了趕上摩爾定律預測的發展速度，光靠量變是不夠的，每一種技術，過不了多少年，量變的潛力就會被挖掘光，這時就必需要有革命性的創造發明誕生-即質變。

而在科技進步的量變過程中，新的小公司是無法和老的大公司競爭的，因為後者在舊有的技術方面有無以倫比的優勢，但是在抓住質變的機遇上，有些小公司會做得比大公司更好而後來居上，因為它們沒有包袱，也比大公司靈活；例如當2G到3G手機的質變上，默默無聞的HTC把Nokia這個2G時代的龍頭老大逼上了當年摩托羅拉的老路，而在通訊晶片設計上，博通和Marvell在相當程度上已經取代了朗訊半導體部門和英特爾相關領域的業務。

反摩爾定律使得IT行業不可能像石油工業或飛機製造業那樣只追求量變，而必須不斷尋找革命性的創新發明，因為任何一個技術發展趕不上摩爾定律要求的公司，要不了幾年就會被淘汰。而大公司除了要保持很高的研發投入，還要時刻注意周圍和自己相關的新技術的發展，經常收購有革命性新技術的小公司，甚至出錢投資它們；而反摩爾定律同時也使得新興小公司有可能在發展新技術方面和大公司處於同一個起跑線上，並且讓它們有可能取代原有大公司在各自領域的地位。

個人補充：反摩爾定律告訴我們，一家科技公司如果和18個月前賣掉同等數量的相同產品，它的營業額將下降一半，這樣讓人憂心的情況其正面效果就是促成該產業進行「量」或「質」的改變，才能創造出新的市場提供生存和發展的可能。

　　而當某個產業成熟到一定程度後，量變的潛力便會大幅下降，這時，須要有革命性的創造（質變）帶領產業演進，此時新興的小公司就有可能趁此和大公司並駕齊驅，甚至超前。

2. 三種定律的交互作用

　　王軍在本章的結語中提到，上述的三種定律合在一起，描述了IT產業中發展規律與宿命；整體來說，IT行業是一個高速發展的行業，在這個行業中發展，猶如逆水行舟，不進則退。

　　也由於安迪.比爾定律的作用，在IT工業的產業鍵中，「看不見摸不著」的軟體和IT服務業反而處於上游，而下游才是「看得見摸得著」的硬體和半導體；因此，王軍也提到，從事IT行業想獲得高利潤，就要從上游入手，從微軟、到Google、再到Facebook，無一不是如此，而唯一的例外是蘋果公司，它是透過硬體再來實現軟體的價值。

    我根據文中的三種定律規則試著繪製出如上的圖表，請先從右側最大的圓看起，摩爾定律產生了藍色的圓形，但馬上被安迪.比爾定律的綠色圓形吃去了大部份，而透過反摩爾定律的作用，分別經由量變和質變會產生更多的藍色圓形，量變產生的是小圓，而質變產生的則是大圓，代表質變會比量變帶來一個更大的新興市場，這些圓圈繼續著這三種定律的週期循環形成更多與更大的圓圈；整體而言，摩爾定律和安迪.比爾定律進行的是供需的變化，而反摩爾定律則持續地擴張著市場。