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裡的重要概念。