L13 系統的製程(12)──Use Case的執行流程

Activity List的Interface Method產出後代表所有的Activity都已經有了統一的入口，接下來要做的是依前述的原則產生Use Case Interface（這通常會在我定義的Service Module那一層），並依照Activity Diagram的內容產出Use Cases層級的Sequence Diagram。

在我的設計方式裡，每個Activity都會指到一個Interface Method，這使得在製作Sequence Diagram時有簡單的對應規則，變成只要專心於流程的製作。在Rose上的作法是在Logical View裡建立對應的Package與其中的Use Case Realization，再依選擇的劇本建立Sequence Diagram，圖表裡呼叫的方法就是之前建立的Interface Method。

在這裡記錄的內容維持在Use Case與Activity之間，未來流程會在Use Case Method的實作進行，利用Activity Diagram與Activity Interface Method就可以交得資淺的Programmer實作出我們想要的功能。Activity的內部要如何實現動作的功能則是SD階段應該做的工作。

不越權的使用能夠侷限住使用關係的層次，不會使Use Case Method直接使用到較低層的物件（通用API除外, 這是給所有層次使用的簡單通用功能）。

L12 輔助的文件(4)──產生Module Interface與Method

在這裡要產生的是Interface與其中的Method宣告，我的作法是從上一篇的Activity List設定轉出。首先要先檢視轉出時需要參考的資訊是否都已經設定到Excel表格中。

產生Interface本身需要Package與Interface Name，Module的可見範圍可以預設為public，不過還是建設設定一個欄位來放置以便應付不同設定的場合。轉換的程式可以依Package確定檔案產出的資料夾，Interface Name產生檔名；同時檔案的內容可以產出package與Interface的宣告。

接下來是Method的部分。Method Name、傳回值與傳入參數型態、名稱都可以從Excel表格取得，再加上Method的可見範圍就能夠產出完整的Method宣告；Excel裡擁有的資訊越完整就可以在不同的需要時設定不同的內容。傳入參數都會有帶入多個的情況，由於傳入時大多彙集成Interface，目前還沒有多過五個的發生，可以定義足夠的輸入欄位在表格。

直接使用Rose製作Interface內容時Interface是散落在Package裡不容易取得清單作比較分析的，但是使用Excel的同時除了得到同樣的產出之外，我們還能有包含所有Activity對應的所有Interface Method，這在檢視與討論時都比較方便。這份文件加上Use Case的Activity Diagram是在SA階段所歸檔的設計文件。

將Excel的格式固定並撰寫對應轉出程式後，未來的任何改變可以在Excel檔案裡修改就能直接匯出為Interface宣告，實作程式若有需要同時修正的都會自動在Eclipse裡註記紅色錯誤標記。這樣的作法不是便利許多嗎？

L11 替代的作法(4)──Module Interface Method

接下來所要做的，是在負責的Module裡為每一個Activity定義負責處理的Method Name；這個Module Method會是未來實作該Activity的程式碼所在。在L04裡所用的Excel表格是此時必須去完成的，我們優先填入對應層次的Module Interface Name，再填入適當的Module Interface Method Name。

以上只是起點，決定Interface與Method後還會發現表格裡還需要更多方法資訊：可見度、傳回值與傳入的參數類型、名稱等等，這些都可以加入更多的column來記錄。其實在這裡所做的意義與在Rose裡定義方法是完全相同的，但是我們可以發現直接在UML上設定Interface後資訊都在各自的Interface裡，而在這裡卻擁有系統所有Activity方法的總清單。

詳細地定義好方法的所有資訊後，接下來需要再一個手續把資料產出為真正的Interface。

L10 系統的製程(11)──Module Interface Method

接下來所要做的，是在負責的Module裡為每一個Activity定義負責處理的Method Name；這個Module Method會是未來實作該Activity的程式碼所在。在Rose裡的所要做的就是逐一在對應的Interface裡加上對應該Activity的Method；對應Interface的意思除了要找出正確負責的Module之外，還要決定方法要被放置在哪一個層次。

決定好放置的Interface後就是加入Method的動作，定義方法的可見範圍（由於Module分別放置到不同Package，所以都是用public）、與傳入的所有參數等等。要記得不管是傳回值或是參數裡所用到的系統物件都必須使用Interface；不過這時完全沒有Class，要用也沒得用。

在決定Activity對應的方法時有一個決策，就是必須決定在API上要將Module傳出去直接使用Module Method，或者是只在API上定義可使用的方法再由內部轉呼叫Module Method。前者的作法需要定義的方法比較少，但是外部呼叫的程式有可能沒有釋放掉取的Module而產生後續的問題；後者的作法因沒有把物件傳到外部相對會比較安全，可是必須在API建立一大堆的對應方法。

如果可以嚴格規定外部只在需要時取得Module並不得記憶下來的話，我比較推薦直接傳出Module的作法，因為在以最短時間完成系統的需求下還是以達成功能的最快作法為優先。

L09 系統軟體架構的層次(1)──Package、Class與Method

在我設計的系統裡，軟體架構的堆疊分為三層，由下而上分別是Package、Class、Method；設計的時候是由下而上一層一層堆積起來的。如果設計上面層次時發現要改變下面層次的結構，這多少反應出下層原先的設計帶有缺失。

Package的設計上，我使用Module的概念加以區隔。把系統比喻成公司的話，Module就等於公司組織的部門，每個Module都有自己應該負責的工作範圍。Use Case藉由數個Module的分工來完成，而Module為Use Case而定義的Interface Method集合，就是它應該負責的全部工作。（Component的設計概念與Module相同）

Class的設計是Package裡的物件佈置，在公司部門裡的人員同樣需要分工，有經理負責管理，有人要負責對外窗口，然後每個人都負責不同的業務項目。在Class的設計上也是如此，依不同的目的放置不同功用的Class。Package與Class放置的時候都同時要考慮Interface與繼承的特性。

Method是唯一為如何做事情而設計的，不管是流程控制或是系統動作都是在這裡面完成；我依照這個方式把方法分工為流程與動作兩類，努力不讓一個Method混用這兩類的意義以避免難以拆解與改變。這到ＳＤ的章節時再作詳細的說明。

只要依序執行過功能所需要的動作方法就一定能完成它，但是藉由Package、Class的佈置，讓各個方法依特性集合起來，在應付不同需要的時候可以提供群組化後的重用單位（元件化）或是快速地更改進行流程（需求變更），這是彈性設計的主要目的。

L08 某個專案裡的Module Diagram產出

說真的，光是佈置Module與Interface就需要不少精力去佈置與討論，在去年底專案進行時對於系統架構陸續花了將近五個工作天才算定稿。不過當時所有人都有共識：要確認所有系統模組後才允許作進一步的設計。

我所做的這個專案是單機執行的系統，只有一個Layer的情況只需要一張Module Diagram就足夠。第一張圖是專案層級的圖，當然比範例圖複雜許多。第二張圖是加上Interface層次後的圖，到這個情況時如果沒有人說明，一定是沒有人看得懂的。

切記Module的意思是要把Activity所要做的動作加以分類，至於Module要如何佈置就要依賴專案團隊予以詳細地討論並確認，在取得共識後才能得到最適合開發的系統結構。

L07 系統的製程(10)──Module Interface的層次

如果製作的只是單次使用的性質，而且功能需求特別到未來幾乎不會再reuse，那麼之前所獲得的Module Diagram就是我們開發的基準。但是想要做一個可以reuse的系統的話，勢必要再為通用Module製作不同reuse基準的Interface關係。

我會為所有的通用Module Interface準備四個不同reuse基準，分別是基本、行業用、系統用與專案專用。專案專用是只在這個客戶才需要的功能，現在的Module Diagram裡的Interface都是專案專用的；系統別是特定行業的特定系統才會使用的；行業別是在那個行業的所有系統都適合的；其他在任何場合都可以使用的功能則放在基本。

分層的好處在於未來的reuse可以直接繼承符合自己需要的那層，但相對的現在得佈置四層Interface（當然未來也有四層class等著實作），同時每一個定義的方法都要逐一確認應該放置到哪裡。大多數人會認為因為未來不確定的需要而在現在花時間去做是很不值得的，所以都只做出專案專用的這層；這樣的作法在未來真有reuse的需要時，就絕對只能copy-paste形成另一套系統再作修改，所以我寧可多花少許時間佈置好這些架構以避免未來更難維護。

哪些Model要切分多個層次是見仁見智的，不過基於要做就一次做到好的念頭，我都會全部一次定義。下圖是兩個Module的範例。

L06 系統的製程(9)──佈置API與Service

對於Subsystem有幾個思考的方向：整個Environment 重新設計？整個Environment全部沿用？或者沿用相同的Factory、Preference、Message等支援Module而只改變MVC的部分？每一個決定都會帶出不同的作法。為了達到最大的彈性最好假設兩者都會被採用，只是每一種作法都會額外多出一些需要設計的管理方式。

在重新設計的情況時，使用Subsystem就像使用一個完全不同的系統，全部Module都要重新設計是免不了的。在沿用相同的支援Module時，所有Subsystem的MVC要實作同一組Interface使之能在Environment裡抽換；此時甚至要在Environment裡加上管理機制來允許多組MVC同時存在。

在系統必須提供一些功能給外部呼叫的時候，需要額外準備稱為API的Module，將系統提供使用的功能都集中定義在這裡；API被系統管理的，裡面定義的會是與Module提供的動作有關。另外會有Service的存在，在這裡放置的則是跟服務有關的功能，也就是使用者想要系統執行的功能；這在未來可以加掛將XML轉換為data model的模組讓Web Service可以使用系統提供的服務。

對應之前提過的兩層式邏輯，Service可以說是系統流程（對應為Use Case），而API裡的是動作流程（對應為Activity）。在我的設計裡，Service可以指定不同的Environment，讓同樣的一套服務程式碼可依設定的不同在不一樣的系統動作。

L05 Rational Tool(7)──使用Package Diagram描繪系統Module

做完上一篇的步驟我們可以得到Class Module List與Server Module List，擁有所有的Module後接下來就是安排每個Layer裡所有Module的組織圖。

首先要篩選出支援性質的Module，像是Preference、Resource Management、Log、Message、Data Model Factory、Data Model Serialization等等，先行安排這類必須要有的後勤Module，這些Module都適合作為Environment下的獨立機制。再來就依系統功能需求安排與Data Model有關的Controller、View、Listener、Event Notifier等執行用的Module。Module若有進一步的說明可以寫在Package Documentation裡。

兩個以上的Module有合作關係時首先找出誰應服從誰的指揮，把指揮者放在使用另一個的位置，如果彼此有相互使用的情形就多安置一個Cotroller Module來負責控制的責任。在我的理論裡，每一個Module都會安置在不同的Package，而操作它們的管道唯有經過定義出來的Interface而已。在安置好一個Module後同時給予一個Interface，再依使用關係拉上線條。

依責任的描述佈置好所有的Moudle就形成了系統的基礎結構。下圖是一個簡單的系統Module組織圖範例，其中虛線所表達的是Module的從屬關係（帶有管理的意義）而非使用關係。