1.4.4-封裝

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

1.4.4-封裝

面對真實世界中的多數物品，我們是「不知」亦能用，多數事件，我們也是「不知」亦能行。當然，我們對多數的事物也不是全然無知，只不過通常是有限度的知。因之，在物品或事件所蘊含的細節都被封裝(Encapsulation)起來的情況下，我們還是可以使用物品、參與事件，毫無困難。

所以，當我們打造軟體物件來模擬真實世界裡的事物時，也模擬了這種封裝特性。由於軟體物件的封裝性，物件之間僅透露足以進行互動的低限資訊。對於物件的封裝性，系統分析師要掌握下列要點：

1.已知操作。物件通常僅對其他物件透露自身的操作，彼此之間透過呼叫(Call)已知的操作來互動。
2.封裝屬性。每個物件封裝著屬性值，不透露給其他物件。
3.封裝方法。每個物件封裝著方法，僅對其他物件透露操作，但不透露其方法。

因此，系統分析師要特別注意，在分析規劃物件的方法時，如果需要與其他物件互動，甚至是使用到物件本身的屬性或操作時，切記要嚴守下列三項要件：

1.不得直接提及物件的屬性。
2.也不得假設物件的執行方法。
3.僅能夠使用到物件的操作。

從上述可以發現，我們為了悍衛物件的封裝特性，犧牲掉許多便利性。好比喝冰飲時不能打開杯蓋，直接暢飲，非得戳一個小洞，透過吸管，小口小口吸取，十分不便。使用吸管有一個好處，不小心打翻時，不會濺得四處都是，然後還得花錢再買一罐。

嚴守物件的封裝性，有一個好處，當需求發生變動而需要改寫程式碼時，變動會被侷限在物件的屬性和方法中，不會起漣漪效應，也不會發生牽一髮動全身的連鎖反應。由於軟體內部的組成物件易於汰舊換新，所以軟體的使用壽命延長，後續的維護成本也偏低，企業因此得到高投資報酬率，不過眼前首先要付出的代價是較高的開發成本。

1.4.3-操作與方法

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

1.4.3-操作與方法

針對物件的操作，系統分析師還必須進一步探問how，了解操作的實行方法(Method)。簡言之，操作是物件的what，而方法則是物件的how。然而，在我們用程式實作出物件之前，物件是死的，它哪會有什麼方法來執行操作。所以，我們其實是想獲知企業人員慣用的操作方法，然後將人為的操作方法轉移給物件，成為物件的操作方法。

系統分析師訪談企業人員時，主要得獲知方法的執行步驟(Procedure)、所需或者產出的資料、計算公式，以及企業的特殊限制。也許，系統分析師可以參考下列問題，向企業人員提問：

1.您(企業人員)通常都怎麼執行某操作的呢？可以告訴我，主要的執行步驟嗎？(探問執行步驟)
2.請告訴我這些執行步驟會需要使用到什麼資料？以及會產出什麼資料？(探問資料的輸入及輸出)
3.請告訴我這些執行步驟會需要使用到計算公式嗎？(探問計算公式)
4.在執行某操作時，有沒有什麼重要的限制需要注意或遵守的？(探問特殊限制)

假設針對基金帳戶物件的「申購基金」這項操作的執行步驟，系統分析師向企業人員訪談的過程中，可能出現如下述的模擬對話：

系統分析師問：您通常都怎麼執行「申購基金」這件事呢？可以告訴我，主要的執行步驟嗎？(探問執行步驟)
企業人員答：是這樣的，申購基金分為兩種：一種是單筆申購，另一種是定期定額申購。
系統分析師問：誰在什麼時候會決定是哪一種？還是可以同時包含兩種？(判斷是否要拆成兩項操作)
企業人員答：客戶一開始在申購基金時，就得二選一，決定是要單筆申購某檔基金，還是定期定額申購。

(對於客戶而言，單筆申購基金或者定期定額申購基金是兩項不同的目的，所以系統分析師決定將原先的圖1-1裡的申購基金操作一分為二，改成圖1-2的模樣。)


圖1-2: 申購基金操作一分為二

系統分析師問：請您挑比較簡單好懂的一種，告訴我您主要的執行步驟？(探問執行步驟)
企業人員答：都很好懂啦，我就先說單筆申購的情況，好了。客戶告訴我們單筆申購的基金名稱、信託金額以及扣款帳號，那我們這邊只要確認這檔基金有販售，然後客戶指定的扣款帳號裡頭有足夠的餘額可以付信託金額和申購手續費，這樣就可以申購了。確認申購之後，我們會從客戶指定的扣款帳號中，支出信託金額和申購手續費。最後，我們會給客戶一個申購交易的憑証號碼，就完成單筆申購了。

系統分析師記錄「單筆申購基金」的主要執行步驟如下：

1.客戶告知(基金名稱)、(信託金額)以及(扣款帳號)。
2.企業人員確認(該檔基金販售中)。
3.企業人員確認客戶指定的(扣款帳號)裡頭有足夠的(餘額)，可以用來支付(信託金額)和(申購手續費)。
4.確認申購之後，我們會從客戶指定的(扣款帳號)中，支出(信託金額)和(申購手續費)。
5.最後，我們會給客戶一個(申購交易的憑証號碼)，就完成單筆申購了。

隨後，系統分析師可以請企業人員協助確認這份記錄，同時給予補充。但是，對於單筆申購基金的操作方法還沒訪談完，系統分析師還得獲知並確認輸出入資料、計算公式以及特殊限制。

1.4.2-屬性與操作

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

1.4.2-屬性與操作

試圖去了解真實世界中任一事物時，有多元的角度可以去探尋，就像佛法有四萬八千法門一般。不過，系統分析師並不需要這麼樣深入了解物件，對於任何一種物件本身，系統分析師只需要針對下列兩項問題去探尋：

1.物件需要記錄哪些屬性(Attributes)？
2.物件可以提供哪些操作(Operations)？

上述的問題可以說的更白話些，或許系統分析師可以向企業人員作如下的提問：

1.某物會記錄什麼資料呢？(探問屬性)
2.某物可以提供我們哪些資料呢？(探問屬性)
3.透過某物，可以讓我們查到哪些資料嗎？(探問屬性)
4.某物可以做什麼用呢？(探問操作)
5.有了某物之後，我們可以拿它來做什麼事呢？(探問操作)

假設我們要開發基金交易平台，來向企業人員進行訪談，期間提到了「基金帳戶」。想像一下，系統分析師跟企業人員之間的模擬對話，大概會像這樣子：

系統分析師問：基金帳戶會記錄什麼資料呢？(探問屬性)
企業人員答：基金帳戶裡頭主要會記錄總成本、總現值、總損益、總報酬率。
系統分析師問：有了基金帳戶之後，我們可以拿它來做什麼？(探問操作)
企業人員答：有了基金帳戶之後，只要裡頭存有足夠的錢，你就可以用它來申購基金，或者贖回基金。


圖1-1: 基金帳戶的屬性與操作

針對物件的各項屬性，系統分析師還需要進一步了解它在企業裡的定義、資料型態(Data Type)、可能的範圍值、或者初始值，更別忘了了解這項屬性是怎麼跑出來的？或許，系統分析師可以向企業人員作如下的提問：

1.可以請您(企業人員)用簡單的一、兩句話，解釋某屬性是什麼嗎？(探問屬性定義)
2.可以請您舉個例子嗎？(判斷屬性的資料型態)
3.請問某屬性有範圍值嗎？(判斷屬性的資料型態以及欄位大小)
3.1可被接受的數字，最大最小為何？(數字型態)
3.2.可被接受的字串，最長最短為何？(字串型態)
3.3.預設的項目，有哪幾個？項目異動的頻率？(列舉型態)
4.請問某屬性有初始值嗎？(探問屬性的初始值)
5.怎樣做才能夠得到某屬性值(Attribute Value)？(探問屬性值的獲得方法)
5.1.請問誰會提供這項屬性值？(鍵入值)
5.2.請問可以向哪裡查詢這項屬性值？(查詢值)
5.3.請問計算公式為何？(計算值)
5.4.請問可有獨特的編碼方式？(流水碼或特定編碼)

1.4.1-物件

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

1.4.1-物件

真實世界由琳瑯滿目的事物所構成，但並非所有的事物都適合對應成軟體物件(Object)。對於系統分析師而言，候選物件應該同時符合下列兩項條件：

1.在企業運作過程中，企業人員會使用到的專業事物或概念。
2.而且，在資訊化時，系統也會用到，或者需要保管。

系統分析師在訪談企業人員時，可以提出類似下述的問句，以便獲知重要的物件。像是：

1.在執行這項工作時，你們會用到哪些專業概念？(探問物件)
2.你們在執行這項工作時，會需要用到哪些資料？(探問物件)

諸如此類的問句，有助於找到重要的物件。軟體公司可以多向資深的系統分析師蒐集此類的智慧問句，甚至編寫成系統分析師通用的工作手冊。

1.4-重要的OO及UML概念

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

1.4-重要的OO及UML概念

OO是一種較為直覺的設計思維，在設計軟體時，讓軟體世界裡的程式物件對應真實世界裡的具體事物，以此來模擬真實世界的運作情況。觀察真實世界可以發現，真實世界由各式各樣的事物所組成，每種事物都有它特有的結構和行為，而且在聯繫起不同事物之後，還能夠展現出豐富多元的能力。所以，OO軟體也由各式各樣的軟體物件所組成，並且合力提供多樣化的服務，以此參與企業運作過程。

OO概念是UML的基礎，也就是說，系統分析師在學習使用UML的同時，其實就是在應用OO概念。換個角度來看，UML與OO兩者互為表裡，系統分析師腦子裡運用的是OO概念，但是表達出來的需求文件內容，卻是使用UML圖。

UML最大的特色，在於它是個圖形語言，因此享有圖形思考與表達的優勢。所以在本書裡，我們除了要求系統分析師在編寫需求文件時，須以UML圖為主，文字為輔外，還要求系統分析師在訪談及討論會議期間，皆須以UML圖引導整個會議進行，並且以產出UML圖為其會議結果。

1.訪談即是繪製UML圖。
2.討論即是修改UML圖。

想像一下，系統分析師帶著安裝了UML工具的筆記型電腦，到使用者或領域專家的辦公處所進行訪談，訪談的產出就是UML圖。系統分析師啟動UML工具的同時，就是訪談的開始。系統分析師開始動手繪製第一張UML圖，也同步開始請教使用者各項問題，一邊繪圖一邊跟使用者澄清認知，以便完成UML圖。依循這樣的過程，產出一張又一張的UML圖。當這些UML圖都繪製並且經過確認之後，系統分析師列印UML圖交給使用者，並且將UML檔案傳回給公司，完成此次訪談會議。

在訪談記錄正式成為需求文件期間，使用者有任何補充，或者系統分析師有任何疑問，都切記以手上的UML圖為討論依據。同樣地，系統分析師提交文件給設計師之後，如果設計師有任何疑問，需要開討論會議的話，也必須以UML圖為討論依據，沒有準備好UML圖，不浪費時間開無謂的討論會議，與會人員沒有修正UML圖，討論會議不算結束。

在了解OO與UML的相關性之後，接下來我們會介紹幾項重要的OO概念，當然它們同時也是UML裡的重要概念。

1.3-UML圖

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

1.3-UML圖

在本書中，系統分析師將學到兩大類的UML圖：行為類的圖(Behavior Diagrams)與結構類的圖(Structure Diagrams)。

行為圖將引導系統分析師分析且釐清「系統該做些什麼？」系統分析師在繪製行為圖時，可以聚焦在系統多方面的動作，像是系統與使用者之間的互動，或者是某種物件(Object)因為事件的刺激以至於發生某些反應動作，以及一群物件互動完成某項服務等等。系統分析師在訪談期間或結束之後，可以透過這些不同功能的行為圖，獲知系統多方面的行為。

系統分析師主要會學到下列的UML圖，它們都歸屬於行為類：

1.使用案例圖(Use Case Diagram)
2.活動圖(Activity Diagram)
3.狀態圖(State Machine Diagram)
4.循序圖(Sequence Diagram)

結構圖將引導系統分析師獲知「系統的重要組成元素是什麼？」通常，透過結構圖將引導系統分析師釐清企業裡(Business)的專有名詞，以及專有名詞之間的關係，以此做為系統的核心結構。其餘，技術面的結構設計就留待設計師去傷腦筋了，這部分並不是系統分析師的工作職責。

系統分析師主要會學到下列的UML圖，它們都歸屬於結構類：

1.類別圖(Class Diagram)