筆者在近日因某些關係與一位已退休的東海大學物理系劉教授聚餐聊天，在談話的過程中我似乎與教授生活在不同的世界一般，可想而知物理是一切科學之本，而教授的思路與談吐都環繞著他們數十年來所追求的真理與中心思想，我想這便是一種思考原則吧！
相對的，若我們將焦點縮小到物件導向設計，它的中心思想筆者由自己的經驗與書籍上可歸納出就是『將真實世界的物體抽象化』，不過這種說法我想對於一般的讀者來說會充滿了疑惑且難以想像，就好像我與劉教授一樣，無法進入他的思考境界一般，因為充滿哲理的說法，是需要很多知識與智慧的結合才能夠體會的。
這篇文章的目的就是為了協助初學物件導向設計的讀者用最簡單的方式將真實世界的需求轉換為類別設計，以筆者的經驗與心得來引導讀者去分析及找出學習的盲點。
筆者在學習物件導向程式設計(C++)過程中，翻過了很多的書籍，跳過每本書的前一至三章說明程式設計的基本功夫不說，大部分書上的內容結構都離不開物件導向程式設計的通則『繼承』、『封裝』及『多形』等，也會給予很多的範例讓讀者練習，不過，當讀者要接觸真實的專案設計時，不一定能立刻將問題及需求轉換為物件導向的設計方法。
其實這是很正常的，因為書上都會盡量以範例來闡述物件導向，缺少了系統分析與設計的部分，因此，大部分的初學者會碰到這樣的瓶頸，筆者也不例外，不過當時並沒有前輩們的指導，協助我如何去思考及實作，所以，只能從實務中去體會學習如何以物件還思考問題了。
為什麼會碰到這個瓶頸呢？我想在於書本上的範例過於強調以一個案例敘述來解釋物件導向程式設計(OOP)的概念，忽略了引述案例所應包含的前因果，讓讀者可以『初步』的去體會或瞭解一些物件導向設計(OOD)的概念，如此極有可能造成剛學會OOP的人，在轉換到OOD時有學習的斷層存在，甚至與資深的程式設計師或分析師討論問題時，也有可能發生溝通上的困難，這個論點我在『物件導向OO技術基礎講座』一書中作者也同樣的點出此問題。
初學物件導向程式設計的人員，不必過於將真實世界的所有事情都要以OO的觀點來看待他，因為此時你所學習到的只是如何去實踐OO系統開發的工具而已，你可能會一直停留在物件導向的reuse或extend等執著當中，所以你會遇到為什麼使用OO會這麼的礙手礙腳的問題，此時別灰心，因為只是你缺少了一些思考的觀點、原則及方法等經驗吧！
需求與類別的關係
在系統開發時的工作要點之一就是系統分析，所謂分析是去找出問題及需求，在物件導向分析中我們經常將分析區分為：
找尋及界定問題的『需求分析』。
找尋問題描述的『物件分析』，經過這兩個步驟之後你就可以初步的找出需求中的物件了。
在需求分析階段，此時是專案開發時最重要也最複雜的階段，是必需經過很綿密的思考及溝通才能產生較為完整的需求，這也必須依賴豐富的經驗與專業素養，甚至良好的公關能力才能順利的完成，所以，當你還是初學者的時候，若身旁有資深的人員帶領那是最好也不過了，若沒有當然還是必須先稍微做一下功課後才去執行此項工作，一方面可以在最短時間內取得客戶對你的信任，另一方面也容易打開彼此之間的關係。關於這方面的問題，我想不需要論述得太多，而筆者這篇文章主要還是把重點放在需求與物件的主題中，所以不再多加闡述。
一般需求分析時，都會先列出系統的參與者(角色)，及針對這些參與者的問題需求寫成描述，這階段對於瀑布式需求分析(Waterfall)或物件導向需求分析等方法來說其實大同小異，就如同『USE CASE』使用案例來說，其實它主要是利用「文字敘述」來描述需求的內容，之後訂定的UML才將Use Case Diagram作為輔助表達參與者與系統之間關係的一種圖形，但在諸多文獻中仍可明確得知，Use Cases的重心仍然在文字敘述，單就這點而言，需求分析的工作並不會因為物件導向的開發而有所不同。
總結來說，在系統分析方法上的主要差異性在還是於『物件分析』階段的思考模式。
瀑布式需求分析階段
物件導向需求分析階段
需求描述
文字描述需求
文字描述需求(USE CASE)
圖形工具
傳統流程圖
Use Case Diagram
System Sequence Diagram
其他
需求轉化為物件之分析
在物件分析階段，主要就是在需求描述的問題的範圍內找出類別來，有時會稱作「問題領域物件」，物件經一般化後便產生類別來，此時你就已經有了系統分析的初步結果了。然而問題往往是初學者對於如何需求敘述中找出類別、方法及屬性也會感到力不從心，因為這才是將系統需求轉化為物件導向系統分析的關鍵所在，不過資深的前輩們也都知道這樣的轉化過程，其實是需要很多的經驗所累積的，而這對初學者而言卻是最難跨出的一步。
因此在本篇文章中，我們先將以簡單的方法來介紹並結合筆者們常用的思考方式來幫助初學者，以期能夠縮短學習的曲線，至於更詳細的內容我們將在往後文章中來作闡述。
筆者們常用的方法中，就如『Applying UML And Patterns』一書中所提的需求分析與物件導向分析與設計的方法中一般，大約可分為四個步驟：
定義使用案例－描述詳細的需求的情境(Use Case)。
定義領域模型－將現實世界的物體抽象或一般化，並找出屬性及關聯。
定義互動圖－將物件與物件之間的訊息傳遞的行為找出來(Sequence Diagram)。
定義設計類別圖－找出物件內的屬性及方法(Class Diagram)。
不過上述的步驟方法大都是已經有該專案的Know how且有OOAD的經驗者之思考及實作的方法，因為他們已經可以憑著經驗，而能夠很直覺得定義出需求中所需的物件、屬性及方法，更進一步的能夠分析出物件與物件之間的關係，不過，筆者整理出下列的方法，可以協助初學者較容易找出上述幾個步驟中可以產出的一些分析文件及圖形：
a、 由需求中找出類別
從每個需求敘述中找出『名詞』來，每個名詞都是類別的候選者，再篩選出該類別可能含有行為及屬性，若該名詞不具備行為(方法)及屬性，則可能是某類別的屬性之一，此方法可對應著上述的『定義領域模型』的步驟。
b、 找出類別的方法
找出需求敘述中的動詞(is、was、have)，這將會是方法的候選者，且透過需求敘述你可以再將這些動詞與上一步驟所找出的名詞結合，繪製出所謂的『互動圖』及『類別圖』。
c、 找出類別的屬性
類別候選者所消除的名詞可能就是某些類別的屬性，這也是『定義領域模型』的一種另類思考的方法。
d、 驗證你的需求
重新驗證需求中的每個敘述，並檢討可能遺漏的必要功能。
結論
關於需求轉為物件導向系統分析的方法諸多繁瑣，而且真的需要經驗的累積，筆者所闡述的是盡量讓初學者得到一些啟發，至於對錯可能都會因人而異，且這個主題充滿了很多的哲理，要描述這些哲理不是一篇短文能夠涵蓋的，因此筆者先以這篇文章作個開場白，因為或多或少在未來的文章裡，大都會提到與本文相關的一些議題，因為這篇文章是物件導向設計與分析的核心，所以，一些關鍵的議題將會在未來為各位說明，敬請期待囉～
沒有留言:
張貼留言