目的
|
改寫模型的結構來反映小組組織或實作語言的限制。
|
請處理與實作環境相關的小戰術問題來決定子系統的組織是否需要改變。以下是這類戰術問題的範例。請注意,如果您決定要變更實作子系統的組織,您也必須決定是要回頭更新設計模型,或是聽任設計模型不同於實作模型。
-
開發小組組織。子系統結構必須容許多位實作者或多個實作者小組繼續平行作業,而不會造成太多的重疊和不安。建議您每個小組只負責一個實作子系統。這表示您可以將子系統分成兩個(如果它夠大),將兩個片段指派給兩位實作者或兩個實作者小組實作,當兩個實作者(或小組)有不同的建置/發行週期時,尤其如此。
-
類型宣告。在實作中,您可能會認識到子系統必須從另一個子系統中匯入工作成果,因為有一個類型宣告在該子系統中。一般而言,當您使用類型化的程式語言(C++、Java 和
Ada)時,便會出現這個情況。在這個狀況下,一般而言,將類型宣告擷取到個別的子系統中,可能是好的想法。
範例
您將子系統 D 的一些類型宣告擷取到新的子系統 Types 中,使子系統 A 與子系統 D 中公用(可見)工作成果的變更無關。
類型宣告是取自子系統 D 中
.
-
現有的舊版程式碼和元件系統。 您可能需要納入舊版程式碼、可重複使用的元件庫,或現成的產品。如果並未在設計中建立這些模型,就必須新增實作子系統。
-
調整相依性。 假設子系統 A 和子系統 B 互相有匯入相依性。不過,您可能會想使 B 比較不依賴子系統 A 的變更。請擷取 B 所匯入的 A 的工作成果,將它們放在較低層的新實作子系統 A1 中。
工作成果取自子系統 A,放在新的子系統 A1 中。
現在,實作子系統已不再 1:1
對映到設計模型中的套件/子系統,您可以在設計模型中進行對應的變更(如果您決定使設計模型緊密符合實作模型),或追蹤實作和設計模型之間的對映(如透過可追蹤性或實現相依性)。是否以及如何進行這類對映是一項應該擷取到工作成果:特定專案專用準則中的流程決策。
|