前言
這篇文章將會講述類圖的基本介紹,並且詳細敘述從零開始製作完整的類圖流程。
類圖
類圖是企劃版本的程式設計,甚至有一群以 UML 為主的程式設計師,他們不負責撰寫程式,專門製作 UML 的各式圖形,我在之前有撰寫一篇文章介紹它的基本介紹及類圖的寫法,詳情可以參考:
一、視覺化程式邏輯
在程式設計之前先繪製 UML 圖,能協助程式設計進行視覺化的幫助,程式有哪些變數、哪些函式,並且在開始撰寫之前用更低成的本與更高的效率進行程式的規劃。
開學後,在新的專案中我嘗試使用 UML 的方式進行程式撰寫,效果雖然沒有到很好,因為我們是規劃完工能後就直接開始撰寫程式,不過有一個視覺化的紀錄效果依然很好。
當我使用 UML 之後,我就能跟另一位程式用比較具體的方式去討論程式設計的內容,哪一個 class 有問題、哪一些函式說的不夠清楚,也能去判斷是否完成功能的實行。
二、功能需求的呈現
在單純的 UML 中,就能看出一個類別的功用與職責,並且能妥善地呈現是否有達成物件導向的單一職責原則,是否疊加了許多不同的功能,還是良好的只執行一個單一功用。
功能需求是我在撰寫這篇文章後想到的部分,因為我撰寫的時候習慣只列出公有函式而非私有函式,因為我以為給其他程式有關連的部分比較重要,。
這時我想到,當初撰寫程式時,其實為了完成單一職責,把函式細分成很多種不同的函式,這應該可以在 UML 階段去規劃,這項功能可以拆分成多少私有的函式。
三、程式腳本的關聯
如果有經歷過那種專案後期,應該有不少人體驗過太多程式碼纏繞,不知道這個程式腳本與哪一個式腳本有關聯,這個值是否會被其他值給改變,有哪些物件會控制這個程式腳本,這些資料都能一目了然。
程式之間的關聯在前期並沒有太大的影響性,因為前期的程式碼並不會太過於複雜,然而在設計程式時,很有可能一再疊加程式碼上去,導致最終的程式碼過於複雜,用 UML 的輔助是很有幫助的方法。
五大流程
我目前撰寫 UML 文檔,主要預計有五個步驟,雖然我目前應該只到第四個步驟而已,不過第五個步驟是我下一步預計要處理的內容,所以我依然寫進這篇文章了。
一、廣泛列舉可能需要的遊戲需求與功能
首先,把遊戲中的「所有」功能與需求列出來,只要腦袋想到一種遊戲功能或遊戲需求,就先寫下來,哪怕重覆也沒有關係,重覆列出腦中飄過的思維,直到腦袋一片空白為止。
基本上遊戲在這一塊會有很多可以處理的內容,包括遊戲管理員、玩家按鍵輸入、主角行動、敵人智能、場景控制等等,把腦中浮現出來了所有內容都列舉出來,並繼續撰寫其中的子功能。
二、分割程式功能,直到不可分割為止
當我們列完所有功能,開始繼續分割,每一寫出來的功能,包括子項目,這個功能是否可以分為不同的單一職責:例如玩家移動,玩家按下按鍵、確定方向、給予推力等等,這一連串的過程初步就能分成三個基礎功能。
這個動作要持續到不可分割為止,現在應該會有很多功能陳列,依照大致上的功能把類似的項目放在一起,以便於下一階段的進行。
三、合併相似的功能與需求
現在我們有了一群以功能分類的項目,把那些相似的功能合在一起,例如玩家跳躍、玩家移動、玩家調查都會使用到 GetAxis 來取得玩家輸入,因此可以把他們之中關於玩家輸入的部分就會合併。
當我們把所有相似功能合併之後,我們就能用這些功能去實現各種不同的功能;除此之外,也適合繼續製作出其他功能,以利維護與擴增,因為之後遇到類似功能的時候,只需要讀取這段資料即可。
四、開始製作 Class diagram
此時就可以開始製作比較詳細的規劃,也就是製作 Class diagram,開始思考比較詳細的變數與函式安排,哪些是私有、公有的變數或函式,逐步規劃每一項前面確定好的功能。
五、排列並增加連接
最後,把這些各自獨立的類圖連接起來,詳細可以參考我之前寫的文章或者網路上提供的教學,類圖的連接比較複雜,不過記得箭頭指向的是關聯對象,而非來源,應該會比較好理解。
後記
這篇文章講述了我對於類圖的理解,裡面有很多項目都是最近的感悟,因此可能有些簡陋或潦草,不過都是屬於比較印象深刻的部分。
瓶裝雪