程序/遊戲設計工作流程

Question

程序員類型：

您是否爲程序或遊戲編寫了大量的設計文檔？ 正在使用UML繪製用例圖的標準方法嗎？ 根據軟件的範圍和團隊中的開發人員數量，您是否運行了整個圖表或各種選擇？

Answer 1

首先，

如果您的文檔，它應該有一個 「清」 的理由/目的。 這個目的是識別你的文檔的性質。

其次：

不要以爲文件只是一個 「書面形式」 或Word文檔。 它可以是任何form.Even它可以是一個「視頻」，其中一些人 說明你的主要架構decisons，爲什麼他們選擇 它[動機]

好吧，假設你想新的團隊成員「輕鬆抓取」你在做什麼，你是怎麼做的，爲什麼你在做這樣。[要當心一切都取決於你的問題的性質]

• UML用例圖可能可以給你的功能的整體畫面 要求。它只是說明誰將使用你的系統，以及他們可以用你的系統做什麼。
• 短備忘錄此狀態下，重要的非功能性需求
• 簡短的備忘錄其中指出你的主要架構決策，爲什麼你把這個決定
• 也許組件圖，它顯示了你的重要組成部分，它們的接口
• 如果應用tapology非常重要，那麼可能是一個UML部署圖，它顯示了你的系統將如何物理部署。

但畢竟你不能證明事情，你不應該。你可以用一個UML工具自動生成整個系統的UML類圖，但這對新手有什麼幫助。

• 但你可以把類圖，爲做重要和棘手的 零件類和繪製序列圖的那些節目的同時，他們的表現很重要和棘手 責任，他們與其他類如何 合作棘手的部分。

爲文件建立的關鍵是puting自己變成你的「觀衆」 [誰 將閱讀您的文件]，並問自己

• 如果我是這個文件potantial「觀衆」將我讀到這文件？ [如果不是你爲什麼做文檔]
• 如果我閱讀這個文檔，它會以某種方式幫助我嗎？[它是有效]

最後，我們並不是生活在「理想字」 ......有時候，你可能會發現自己做的文檔沒有真正的觀衆和沒有真正的理由只是因爲一些「政治」和你應該賺錢

那麼，在這種情況下，UML將有所幫助。繪製無聊，有許多細節[通常aulectumatically生成]圖表，沒有人閱讀或理解，但說「哦，你有大量的文件」。在我們的軟件行業中，UML被過分強調了，如果有UML圖，許多人甚至會「買」甚至是壞的文檔。

這就是所有人...