分割要實作的分散式系統方案
更新：2007 年 11 月
當開發小組已經準備好要實作支援實作之應用程式圖表 (Diagram) 上的應用程式定義時，開發組長可以在 Visual Studio 中為這些定義產生專案。這些專案會與相同方案中的其他項目一起顯示於 [方案總管] 中。然而，其中可能會有您想將該方案分割成較小方案的案例。建立較小的方案使其只包含應用程式的子集，對於組織開發的專案而言是比較彈性的方式。Visual Studio 讓您可以在不限數目的方案中包含專案，因而可以建立包含專案子集的方案。此外，這在保留原始方案以做為「主要」方案時十分有用，因其能讓橫跨方案之原始範圍的變更趨於一致，以及在該範圍內建立系統和定義部署。
.gif "注意事項") 注意事項： |
|---|
本主題的處理方式和指引會假設使用原始程式碼控制。如需詳細資訊，請參閱受原始檔控制的系統定義模型 (SDM) 文件。當分割方案時，建議您在檔案系統架構的 ASP.NET 應用程式 (預設使用動態通訊埠) 上使用靜態通訊埠。在 ASP.NET 應用程式上的動態連接埠可能會造成其 Web 服務上的通訊埠編號變更，進而導致對應的 Web 參考中斷連接。如需詳細資訊，請參閱應用程式圖表上的 ASP.NET 應用程式概觀。 |
以下幾節的內容會包含分割方案的詳細資訊：
從主要方案分割的方案
將原始方案保留為主要方案
以分割方案的變更更新主要方案
從主要方案分割的方案
對於在單一方案中針對大型且複雜之應用程式系統建立應用程式定義的案例而言，將方案分割為較小的方案以實作應用程式，可能會比較容易管理。每個分割的方案都會包含應用程式定義的子集及其對應專案，而專案中會包含程式碼檔案、組態檔和 .sdm 檔案，這些檔案會包含關聯之應用程式定義的系統定義模型 (SDM) 資訊。
您可以採用各種分割方案的策略。例如，如果整個系統是由輪廓清楚的成員系統所組成，則您可以選擇根據方案中每個系統的界限建立方案。然後，每個方案就會包含各自系統所參考之應用程式定義的專案。依據每個系統複雜度的不同，這些分割的方案可能會進一步地分割為更小的方案。您也可以將方案分割為個別開發人員的層級，讓每位開發人員的方案中只會包含他們所負責的系統部分。也可以使用原始程式碼控制共用專案。不過，請注意在共用專案時會產生某些問題。如需詳細資訊，請參閱對系統定義模型 (SDM) 文件同時進行的簽出和變更。
| 注意事項： |
|---|
即使系統界限會提供邏輯基準，可以用於將應用程式定義及其專案從單一方案分割成較小的方案，但是並不一定要用這樣的方式來分割方案。在系統重疊 (包含相同應用程式定義之使用) 的案例中，這個方式較不實用。 |
分割之方案的內容
您可以將應用程式圖表加入至每個分割的方案，讓應用程式定義會根據該方案之專案中的應用程式定義 (.sdm) 檔案，顯示於圖表上。分割處理後，任何加入至方案的新專案會在需要時，於應用程式圖表上進行反向工程處理。每個分割的方案也可能會包含系統圖表，因此每個人就可以檢視包含使用這些定義的系統。例如，共用對同一應用程式定義之參考的系統圖表可以包含於同一個分割的方案中，藉以提供內容。如果您要使用分散式系統設計工具來評估部署或產生部署報告，則可以使用應用程式圖表，或是將系統圖表加入至分割的方案中。如果您只想針對專案部署使用分割的方案，則方案中不需要顯示任何分散式系統圖表。
| 注意事項： |
|---|
如果您在應用程式圖表處於關閉狀態時刪除了 .sdm 檔案，下一次開啟包含該專案之方案中的應用程式圖表時，會重新產生 .sdm 檔案。然而，這個重新產生的 .sdm 檔案只會包含可以從其他來源重新建立的資訊。任何只儲存於已刪除之 .sdm 檔案中的資訊將會遺失。此外，相關定義的參考也可能會中斷。如需詳細資訊，請參閱應用程式圖表疑難排解。如果共用之應用程式定義不在分割的方案中，則方案中所包含之系統圖表上該定義的使用會顯示為中斷。無法嘗試定義或評估參考遺漏之應用程式定義的系統部署，即使做了也不會成功。如需詳細資訊，請參閱跨系統定義模型 (SDM) 文件的同步處理。如果加入了任何系統圖表，則必須有應用程式圖表存在。 |
將原始方案保留為主要方案
將方案分割為較小的方案後，您也可以將原始方案保留為「主要」方案。使用這個處理方式，即可偶爾檢視和檢閱整個系統。此外，如果有主要方案存在而且包含它自己的應用程式圖表，則不需要使用分割的方案各自的應用程式圖表。
| 注意事項： |
|---|
不需要保留或維護主要方案。例如，如果可以根據 Web 服務之間的連接清楚分割系統界限，就足以管理每個分割的方案，以及表示它們連接至外部 Web 服務的互動。外部 Web 服務會自動加入至每個分割之方案 (Web 服務參考方案界限) 的應用程式圖表中。如需詳細資訊，請參閱可用來定義應用程式的應用程式類型和原型。然而，如果您要設計較高階的系統，該系統參考到較低階之分割方案中所建立的系統，則可以建立只包含必要之較低階系統定義的系統定義。但是，為了要定義和評估這些系統的部署，請確定該方案會包含所有參考的應用程式。 |
例如，假設開發小組是由三位在三個個別方案上工作的開發人員所組成，則每個分割之方案都會包含與應用程式定義相關聯的專案。這三個方案是較大之分割方案的一部分，而這個較大的方案會包含單一應用程式系統的界限。分割的方案會依序成為其他眾多方案的一部分，說明其他的應用程式系統，這些系統會構成主要方案範圍內的整個系統。
因為開發小組在分割的專案上工作，他們會將各自的變更簽入原始程式碼控制。開發組長就可以藉由簽出適當的圖表和檔案，從原始程式碼控制更新主要方案。這個動作會同步處理對程式碼和具有適當圖表之組態檔的變更。如需詳細資訊，請參閱系統定義模型 (SDM) 概觀 和系統定義模型 (SDM) 文件之間的關聯性。
以分割方案的變更更新主要方案
應用程式架構設計人員、開發組長或負責系統架構的人員，可以定期用對分割之方案所做的變更來更新和驗證主要方案。該人員可以簽出包含專案之分割的方案，而這些方案已根據開發小組進行分割，所以開發小組的人員可以直接在分割之方案的專案上或是進一步分割之方案的專案上工作。
如果有架構性的變更，則在檢視整個系統、驗證整個系統設計是否依然配置正確，以及傳送方案之間的變更時，這會非常有用。如果方案只包含橫跨所有方案的應用程式圖表，且是唯一需要維護系統的地方，則定期更新和檢視主要方案也很重要。
在從原始程式碼控制重新整理專案之後，開啟主要方案的應用程式圖表時，應用程式架構設計人員或開發組長可以檢視變更這些專案圖表時所造成的影響。若要查看確切的變更，架構設計人員或開發組長可以檢視已簽入的變更清單，或比較程式碼檔案的差異。然後，架構設計人員或開發組長就可以同步處理應用程式圖表與專案程式碼，或解決任何同步處理的警告，方法是簽出必要的專案，讓需要進行的變更可以在應用程式定義及其在系統定義中的使用之間傳送。
如果架構設計人員或開發組長滿意專案的變更，就會將變更簽入方案中。否則，架構設計人員或開發組長應該與開發小組協同解決任何衝突，讓程式碼可以與圖表同步化。