作業: 實作設計元素
這項作業說明如何產生設計組件的實作(如類別、使用案例實現化或資料庫實體),或修正一或多個問題。結果通常是新的或修改過的程式碼和資料檔,通常稱為實作元素。
關係
步驟
準備實作
瞭解作業/問題

在開始實作作業之前,實作者必須明白工作指派和反覆計劃中所指定的範圍。實作作業的焦點可能在於實現某些特定功能(如實作設計使用案例實現化或修正問題),且這些功能涉及實作若干參與這項功能的設計元素。另外,您也可以將實作作業的焦點放在特定設計元素上,如設計子系統或設計類別,在現行反覆所需要的範圍內實作它。

配置開發環境

這項作業會導致建立或更新一或多個檔案(實作元素)。在準備實作時,實作者必須保證開發環境的配置正確,以便能夠使用正確的元素版本,即將更新的元素及編譯和單元測試所需要的任何其他元素都包括在內。實作者必須知道,也必須遵循專案的配置和變更管理程序,這些程序會說明如何控制變更,將變更版本化,以及如何交付整合它們。

分析現有的實作

在從頭開始實作類別之前,請考慮是否有現存的程式碼可以重複使用或改寫。瞭解實作在哪裡配合系統其餘部分的架構和設計,可協助實作者識別重複使用的機會以及確保實作符合系統的其餘部分。

漸進實作

建議您以漸進方式來實作;請每天編譯、鏈結和執行某些退化測試兩三次。請務必瞭解,並非所有公用作業、屬性和關聯都是在設計期間定義的。

當處理問題時,請確定您已修正問題,而不只是症狀;焦點應該在於修正程式碼中的基礎問題。請每次進行一項變更;由於修正錯誤本身就是一項容易出錯的作業,因此,以漸進方式實作修正,以便更容易找出任何新錯誤的來源,這一點很重要。

實作者必須知道,也必須遵循任何特定專案專用的實作準則,其中包括特定程式語言的程式設計準則。

將設計轉換成實作

將設計轉換成實作的技術有許多種。以下是一些範例:

  • 您可以利用特定平台專用視覺化模型來產生起始程式碼架構。之後,您可以利用設計所未指定的其他程式碼來進一步詳述這個程式碼架構。
  • 模型可以很詳細,且用來產生可執行的原型。結構(類別和套件圖)及行為圖(如狀態和活動圖)可用來產生執行碼。您還可以依照需要來進一步修正這些原型。
  • 模型可以詳細到足以完整代表實作。在這個情況下,並不需要將抽象設計轉換成程式碼實作,您可以利用設計,將實作細節直接加到模型中。
  • 設計可能在不同程度上與特定平台無關。特定平台專用的設計模型,乃至於特定平台專用的程式碼,都可以透過套用各種高階抽象特定平台專用元素之對映規則的轉換來產生。這是物件管理團體 (OMG) 模型驅動架構 (MDA) (http://www.omg.org) 計劃的焦點。
  • 您也可以套用標準型樣,從相關的設計和實作產生設計和程式碼元素。例如,您可以將標準轉換型樣套用到資料表上,以建立存取資料表的 Java 類別。另一個範例是利用 Eclipse 建模組織架構 (http://www.eclipse.org/emf/) 模型來產生儲存符合模型之資料的程式碼,以及產生用來移入資料的使用者介面實作。

不過,無論如何,總有些抽象設計會詳細化成為實作,可能是以手動方式,也可能是套用某些自動化的轉換。

完成實作

如先前各步驟所說明,設計轉換成實作會產生不同程度的實作完整性。它可能是完整而可接受的實作。不過,完成實作通常還有待於大量工作,例如:

  • 調整轉換結果(例如,改進效能,或改進使用者介面)
  • 加入遺漏的細節,例如:
    • 完成「設計 - 選擇演算法和撰寫程式碼」中所說明的作業。
    • 加入其他支援的類別、作業和資料結構
評估實作

這是您驗證實作是否符合目的之處。除了測試(說明在其他作業中)之外,一些其他檢查通常也很有幫助:

  • 用心閱讀程式碼。請考慮保留一份您個人的實作常犯的錯誤核對清單,並找出這些錯誤。
  • 利用工具來檢查程式碼錯誤。例如,靜態程式碼規則檢查程式,或設為詳細警告層次的編譯器。
  • 使用程式碼視覺化工具。程式碼視覺化可協助實作者識別各種型樣,例如過度耦合、循環相依性等。
回饋設計

當實作和測試各項設計時,必然會發現錯誤,通常是會影響設計的錯誤。如果維護抽象設計是為了未來的維護工作,或為了概念或溝通,就必須更新設計。

怎麼做會隨著專案的配置和變更管理程序而不同。一般而言,如果所需要的變更很小,且類別是由同一個人來設計和實作,就不需要正式的變更要求。個人可以在設計中進行變更。

如果所需要的變更影響範圍很大,例如公用作業的變更,您可能需要提出正式的變更要求。



內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊