專案染上分析癱瘓症的十大徵兆

從這幾回所談的十五條分析癱瘓警訊，可以歸納出專案發生分析癱瘓症時的十大徵兆。不過，我們先看完最後三條警訊，編號13到15，這都是跟通訊圖（communication diagram）與狀態圖（state machine diagram）有關的警訊。

原先在UML1中，通訊圖稱為「合作圖」（collaboration diagram），到了UML2才改名為「通訊圖」。

通訊圖與狀態圖，兩者都適合用來表達系統的動態行為。不過，它們比較適合用在即時系統（real-time system）的開發上，鮮少用在商用資訊系統（MIS）上頭。所以，它們在ICONIX方法中，才會列在動態模式外頭，如圖1所示。

圖1：通訊圖與狀態圖


通訊圖
通訊圖和循序圖一樣，適合用來表達一群物件之間的互動情況，所以這兩款圖也合稱為「互動圖」（interaction diagram）。

狀態圖
狀態圖可以讓我們聚焦在單一種類的物件本身，表達物件一生中可以出現的狀態（state）變化。

分析癱瘓警訊
此處我們將繼續討論十五條分析癱瘓警訊中，編號13到15最後這三條跟通訊圖與狀態圖有關的警訊。

染上了分析癱瘓症的十大徵兆
如果你的UML專案出現了下列十種徵兆，那很可能已經染上了分析癱瘓症。

跟需求有關的十大要項
上述的十大徵兆中，有好幾項都跟需求有關，以下是跟需求有關的十大重要事項。通訊圖

通訊圖和循序圖一樣，適合用來表達一群物件之間的互動情況，所以這兩款圖也合稱為「互動圖」（interaction diagram）。由於，這兩款圖所蘊含的內容大致相同，所以在ICONX方法中，兩款圖的開發是二擇一，可以選用循序圖或者選用通訊圖。多數的UML開發工具都有提供轉換兩圖的功能。

此處，我們簡單比較通訊圖與循序圖之間的主要差異，條列如下：
˙呈現敘述文字—通訊圖無法呈現敘述文字，但是循序圖可以讓我們將使用案例敘述放置於圖面的最左方。

˙片段的設計—通訊圖無法表達片段設計，像是前面我們有使用過的引用片段等等的片段通通無法呈現，不利於片段設計之重用，也無法表達控制流程的設計。

˙物件之連結—在循序圖中，沒有呈現物件之間的連結；但在通訊圖中，物件之間的連結是焦點所在。所以，透過通訊圖的物件連結，立即就可以明白兩物件之間必須先建立起連結，隨後才能傳送訊息。

˙訊息的順序—循序圖擅於呈現依序發送訊息的情況，即便隱藏了訊息的序號，從圖面上仍舊可以清楚獲知由上而下依序發送訊息的互動狀況，如圖2所示。可是反觀圖3，隱藏序號之後的通訊圖，幾乎是無法閱讀的。

圖2：由上至下循序發送訊息


圖3：隱藏訊息序號
狀態圖

狀態圖可以讓我們聚焦在單一種類的物件本身，表達物件一生中可以出現的狀態（state）變化。相較之下，狀態圖的觀點與通訊圖或循序圖的觀點全然不同，通訊圖表達某一種物件與其他種類物件之間的互動情況。簡言之，通訊圖用以表達物件外部的互動行為，而狀態圖表達物件內部的狀態變化。

系統分析師經過了繪製狀態圖的思考過程之後，可以對重要物件的狀態變化更加清楚。實務上，系統分析師通常會用一張狀態圖呈現某一種重要物件一生的行為。從物件誕生到滅亡期間，它會對哪些事件（event）有所反應，因而轉換（transition）其內在狀態，並且執行某些特定的活動（activity）。

針對物件一生中可能執行的一組活動，可以使用狀態來分組這些行動。因此，物件一旦轉換進入某一個狀態之後，其可執行的活動就會被限制，直到外界發生了重要事件之後，物件才會從當下狀態轉換到另一個新狀態，同時也將執行新狀態內部規定好的活動。

以Skype這類的網路通話系統為例，我們設計了用戶物件來對應真實世界的用戶。針對通話服務，我們可以繪製通訊圖或循序圖來表達用戶物件與其它物件之間的互動，此時我們可以看到用戶物件在通話這段期間，與其它物件之間的互動。但是，如果我們想要看到用戶物件從誕生到消滅之間，全時期的變化狀況的話，這就超出通訊圖的表達範圍了，而必須改用狀態圖來表達用戶物件全時期的生命週期。

請看到圖4，這是一張用戶物件的狀態圖。狀態圖中簡單地將用戶物件的一生區分成四個狀態，分別為：離線、上線、連線和通話，經由不同事件的刺激，會導致用戶物件轉換狀態。用戶物件處在某一個狀態中，將執行某些活動，並且當外界發生特定的事件時，用戶物件也會從當下的狀態轉換到另一個新的狀態。

圖4：用戶物件的狀態圖


因此，系統分析師透過這張狀態圖，不但可以明確且精準地表達出用戶物件全時期的行為，同時還能夠規範所有用戶物件在任一張通訊圖中的片刻行為，不得超出狀態圖所呈現的物件行為。

狀態圖可簡單也可複雜，有些狀態圖只有簡單幾個狀態，也有一些狀態圖呈現出多層級的狀態設計。

實務上，狀態圖鮮少用在商用資訊系統上，通常使用在即時系統的開發上。有些原文書上有提到將狀態圖用在商用資訊系統的畫面設計上頭，不過我參與臺灣專案多年的經歷中，倒是沒遇到哪個商用資訊系統的UML專案有使用狀態圖的。分析癱瘓警訊

此處我們將繼續討論十五條分析癱瘓警訊中，編號13到15最後這三條跟通訊圖與狀態圖有關的警訊。

分析癱瘓警訊13 如果物件只有兩個狀態時，千萬別為它繪製狀態圖。（Don't do state diagrams for objects with two states.）

分析癱瘓警訊14 如果你不是真的需要模式，那就別建模。（Don't model what you don't really need to model.）

分析癱瘓警訊15 別因為你懂得狀態圖，就一定要繪製。（Don't do state diagrams just because you can.）

其實，這三條分析癱瘓警訊談得是同一件事情，就是—別因為懂得如何繪製狀態圖，就以為一定得製圖，或者為了展現自己的能力而製圖。況且，無論是採用某一款圖，或是繪製某一張圖，都是需要花成本的，學習成本也好，製圖成本也好，所以最好是有需要的時候，才動手繪製UML圖。染上了分析癱瘓症的十大徵兆

注意，如果你的UML專案出現了下列十種徵兆，那很可能已經染上了分析癱瘓症：
徵兆1 在靜態模式中的每一條結合關係的兩端，放置個體數目。（Put cardinality indicators on each end of every association on your static model.）

徵兆2 為每一條功能性需求，撰寫一份使用案例敘述。（Write one use case for every functional requirement.）

徵兆3 為每一張循序圖繪製一張對應的通訊圖，只因為通訊圖是UML的一部分。（Do a collaboration diagram to go with each sequence diagram, because collaboration diagrams are part of the UML.）

徵兆4 每一張通訊圖都對應一個完整的腳本，而不是聚焦在重要的流程上頭。（Cover the entire scenario in every one of your collaboration diagrams. Don't focus on the key transaction.）

徵兆5 為靜態模式中的每一個類別繪製狀態圖。（Draw state diagrams for every class in your static models）

徵兆6 花數小時在不重要的訊息序號上頭。（Spend hours fiddling with the message numbers on your collaboration diagrams.）

徵兆7 為整個系統繪製一張龐大且多層級的狀態圖。呈現出至少有五個層級的子狀態。（Draw one huge multilevel hierarchical state diagram for the entire systems. Show at least five levels of substates.

徵兆8 直接從需求層級的使用案例觀點，跳到循序圖的細部設計。不費心在初步設計上頭。（Jump directly from requirements-level use case views into detailed design with sequence diagrams. Do not pass go; do not collect $200; do not bother with preliminary design. （Do not call me to ask why you're stuck.） ）

徵兆9 在需求模式完成之前，做了太多細部設計，然後又在完成需求時，花費一堆時間重做設計。更甚者，在完成需求模式之前，就先寫了一大堆程式碼。（Do lots of detailed design work before the requirements model in finished, then rework the design a bunch of times as you're finishing requirements. Even better, write a lot of code before finishing the requirements model.）

徵兆10 建構出一堆的狀態圖，而且每一張狀態圖中僅包含兩個狀態。（Create hundreds of state diagrams, each containing two states.）跟需求有關的十大要項

上述的十大徵兆中，有好幾項都跟需求有關，以下是跟需求有關的十大重要事項。

要項1 專案團隊必須盡早條列出完整的需求事項，而不是先編寫程式碼。（The project team shall make as complete a list of requirements as possible, as early in the project as it can, rather than start off with code.）

系統分析師建構的靜態模式和動態模式，都是為了達成功能性需求裡頭的規定事項，而程式碼則是系統達成功能性需求的最終產出。所以，UML專案開發的一開始是先釐清功能性需求，隨後將這些功能性需求分配到靜態模式與動態模式中，最後產出的模式與程式碼都要能夠反向追蹤到原始的功能性需求處，如圖5所示。

圖5：功能性需求


要項2 需求是需求；使用案例是使用案例。需求不是使用案例；使用案例也不等同於需求。（REPEAT AFTER ME： Requirements are requirements; use cases are use cases. Requirements are not use cases; use case are not requirements.）

需求、使用案例和操作，這三項概念很容易混淆。簡單來說，需求、使用案例和操作三者的定義，條列如下：
˙需求（requirement）：使用者規定系統必須達成的事項。

˙使用案例（use case）：使用者為了獲得某項服務或產出，而與系統彼此互動的使用過程。

˙操作（operation or function）：系統的單獨動作（individual action）。

雖然，需求不是使用案例，使用案例也不等同於需求，但兩者密不可分。一般而言，一個使用案例可以處理多項需求，一項需求也可能由多個使用案例來實現。

要項3 需求分為好幾種，像是功能性需求、性能需求，以及限制條件等等。（There are several types of requirements, including functional requirements, performance requirements, and constraints.）

以下列出幾種常見的需求種類：
1.功能性需求（functional requirements）：譬如，線上購物系統必須自動傳送電子發票到顧客的電郵信箱中。

2.資料需求（data requirements）：譬如，線上購物系統的日期格式必須是yyyy/mm/dd、yyyy-mm-dd和yyyy.mm.dd三種。

3.性能需求（performance requirements）：譬如，使用者登入線上購物系統時，系統必須在5秒鐘內做出回應。

4.產能需求（capacity requirements）：譬如，線上購物系統要能夠同時維護1,000筆購物交易。

5.測試需求（test requirements）：譬如，5,000個用戶同時上線時，線上購物系統要能正常運作。

要項4 在需求復審的時候，專案團隊至少要挑選一個使用案例，展示該使用案例對應需求。（The project team should demonstrate connection of at least one use case directly with each requirement during requirements review.）

要項5 在需求復審的時候，專案團隊至少要挑選一個類別，展示該類別對應需求。（The project team should demonstrate connection of at least one class directly with each requirement during requiremnets review.）

要項6 專案團隊必須能夠追蹤需求配置到使用案例與領域類別的情況，這是需求復審的一部分。（The team shall trace the allocation of requirements to use cases and domain classes as part of the requirements review.）

雖然，需求的概念和圖示不是UML標準的一部分，不過許多的付費UML工具都有提供相關的功能。譬如，知名的UML工具——EA（Enterprise Architect）就有支援，需求與使用案例及類別之間的實現對應。請看到圖6，我們新增了兩個需求，分別名為：信用卡結帳和傳送電子發票。

信用卡結帳和傳送電子發票都是功能性需求，其內容為：
˙信用卡結帳——線上購物系統接受顧客使用信用卡結帳。

˙傳送電子發票——線上購物系統必須自動傳送電子發票到顧客的電子郵件信箱中。

圖6：需求


接著，我們新增一個名為「結帳」的使用案例，並且用它來實現信用卡結帳和傳送電子發票的功能性需求，如圖7所示。

圖7：使用案例


此外，我們也新增兩個領域類別，分別名為：信用卡和訂購交易，並且用它們來實現信用卡結帳和傳送電子發票的功能性需求，如圖8所示。

圖8：領域類別


要項7 使用案例模式是開發商與發起者之間的微型合約。每一個使用案例都是開發流程的輸入值，也都是使用者驗收的測試案例。（The use case model shall serve as a collection of mini-contracts between developers and the sponsors of the new system. Each use case shall serve as both input to the development process and as a user-acceptance test case.）

每一個使用案例都像一個微型合約（mini-contracts），記載著使用者可以經由什麼樣的使用過程，獲取系統提供的具體服務或產出。

所以，從開發流程的一開始，到開發出系統後的最終驗收，都以使用案例為中心，連結起相關的需求、分析、設計、程式碼和測試。

要項8 使用案例敘述必須出現在循序圖中，以便提醒開發人員注意這個像合約般的需求。（The text of each use case "contract" must appear on a sequence diagram so that the development team is constantly reminded of the "contractual requirements" they're working against as they do the design.）

要項9 細部設計應該反應在循序圖裡，謹防使用案例敘述成為設計復審的一部分。（The detailed design, as reflected in you're sequence diagrams, shall be defended against the use case text as part of design review.）

循序圖表達了系統內部運作的細部設計，而使用案例則是呈現系統與外界使用者之間的互動，兩者的觀點有很大的差異；循序圖主內，使用案例主外；循序圖重視系統的how，使用案例重視系統的what。

所以，雖然使用案例敘述可以放置在循序圖面上，用來提醒開發人員注意使用案例的規範，但是卻不可以將細部設計撰寫在使用案例敘述中。

要項10 針對每一項需求，至少要有一個測試案例來驗證它。（There shall be at least one test case in place to verify each requirement.）

如同需求概念，雖然測試概念和圖示不是UML標準的一部分，不過許多的付費UML工具也有提供相關的功能。

下一期將進入「實作」(implementation)，這是ICONIX方法中的最後一個步驟，也是「分析癱瘓」的最終回。