1. 首頁
  2. 問答
  3. 有沒有什麼好的資源討論創建和使用UML組件圖？

有沒有什麼好的資源討論創建和使用UML組件圖？

2010-01-03 50 views
4

作爲任務的一部分，我必須爲現有代碼創建組件圖。我瞭解組件圖是什麼以及它提供的信息，但我不確定在查看代碼以繪製出組件圖時要遵循的過程。我也沒有銷售組件圖，如果我有一個組件圖，會幫助我實現一個系統。有沒有什麼好的資源討論創建和使用UML組件圖？

來源

2010-01-03 Thomas Owens

+0

所有的UML圖是「可選」 - 如果你沒有找到特定的一個有用的，不使用它。 – 2010-01-03 22:41:53

+2

是的。但我懷疑這是一個可以接受的答案。 – 2010-01-03 22:43:55

+0

我以前從來沒有使用一個，但我想如果我曾經遇到的需要，我應該能夠（1）實現時，組件圖是正確的工具，整個讓我的消息，（2）能夠根據組件圖（等等）閱讀和實現系統;（3）使用正式的UML或其他類似的符號創建組件圖。 – 2010-01-03 22:48:35

回答

1

對我來說UML主要不是幫助我設計一個系統（儘管它確實有幫助）。這是關於幫助我通過給我們一個共同的語言/符號來將設計傳達給他人。

它使對話更容易，所以我們不會浪費時間在我們不同的參考框架之間進行翻譯。

來源

2010-01-03 22:35:10 Glen

2

您陳述了兩個不同的問題：如何從代碼到圖表，以及如何使用代碼作爲實現系統的指南。如果您正在繪製現有代碼，我認爲第二個問題不適用。

如果你正在設計新的代碼，那麼組件圖可以是1）有用的抽象，用於理解代碼的重要部分，減去所有分心，以及2）與其他人溝通的好方法。

如果您正在查看現有代碼，那麼現有組件圖（或其他幾個UML構件之一）可以作爲代碼的指南，這對維護尤其有幫助：可以更容易地識別錯誤，主要類別責任等。

如果沒有圖表，那麼通過閱讀代碼來編寫代碼的練習是熟悉自己的好方法。在許多情況下，我在繼承一個複雜的代碼庫時已經做到了這一點。因此，我有幾頁的應用程序和數據庫圖表，一目瞭然地告訴我關於其主要組件的有趣事情。在任何時候，我都會對某些領域而非其他領域非常熟悉，具體取決於我正在從事的工作。這些圖很好地提醒您如何使用應用程序的各個部分。他們在將其他人帶到球隊時很有幫助;他們在走完圖表半小時之後就能更快地理解代碼。

要從現有代碼工作，您需要通讀它，識別正在使用的主要類，並追溯以瞭解它們用於協作的依賴關係和接口，方法簽名和數據結構。如果它是數據庫支持的應用程序，那麼查看數據庫的描述會很有幫助，因爲它應該體現應用程序的主要關注點。

它有助於有一些用例來指導調查，因爲使用事件驅動的應用程序，您需要了解用戶正在執行的操作以便跟蹤代碼。如果沒有現有的使用案例，那麼請自己寫一些簡單的高級案例。然後按用例查看代碼，並確定正在使用的主要對象。希望你會在程序中找到主要的類來幫助你識別你的主要用例。例如，如果應用程序是一個具有管理用戶界面的基於Web的電子商務應用程序，那麼您將識別許多最終用戶和管理用戶使用案例，並且應該期望看到特定於每個應用程序的某些類這些家庭以及通用和實用類。

保持在較高的水平，避免考慮你遇到的每一件事的誘惑。

正如帕斯卡說的，斯科特安布勒是一個實用的UML知識的偉大資源，並且具有可以儘可能少或不必要地使用的guildelines。具體見Introduction to UML 2 Component Diagrams。 Hoever，他爲設計新代碼的人編寫的代碼遠遠多於那些記錄現有代碼的人，所以你必須修改他所討論的一些內容。

來源

2010-01-03 23:07:45 Val

2

Martin Fowler的「UML Distilled"仍對UML的最好的書，你可以得到它的主要優點是，它的薄 - 密密麻麻與信息

來源

2010-01-03 23:21:19 duffymo

+1

假期休息後我回到學校時，我在家裏離開了那本書。不過，這本書是一本好書，我相信現在擁有它會很棒。 – 2010-01-03 23:35:23

1

  • 斯科特Ambler是另一個很好的現成的架子。標準答案但是，在組件圖的情況下，我發現（Section Creating Component Diagrams）下的建議很好，但很長，與您的文檔需求無關。從Scott的列表（創建組件圖）我真的只關注（1，4， 5,13），因爲很多建議都是設計最佳實踐，我會在下面添加一些我自己的更多。

  • Martin Fowler的書在很多方面都很出色，但對於組件圖或公司並沒有深入的瞭解。一個巨大的7頁，顯示了他在寫作期間的優先級，因爲班級圖可以達到18頁左右。

  • 我同意你應該能夠實現何時使用UML圖。 UML 2.2規範本身說它是爲面向組件（服務/接口）的系統而構建的。採用基本的MVC GUI應用程序並推入組件圖/模型確實沒有意義。還有一些圖表組件關係的圖表，Scott Ambler's site在圖1中顯示了它們。對於大型多系統實現，我發現這些圖很有效，例如，大量的接口和大量的系統抽象。

我的建議：（我用的組件建模的時候，和我讀了這東西的UML規範）

  • 跳過使用的端口爲HL組件圖，它們是分組雖然他們在斯科特·安布勒的圖表中看起來很有趣，但你不會爲此付出很多努力。

  • 避免陷入內部組件結構。只有在高度複雜的情況下需要清晰度的情況下才能做到這一點。

  • 不要滑入製造大部分「類」的組件。

  • 關注接口和真實邊界的存在，線索是公共接口，包分組，WSDL，外部系統交互。

  • 對於你的第幾個我會開始自上而下。首先進行所有外部系統交互之一，然後進行下一級別的操作，如果需要使用端口和複合結構，但我不喜歡它們，它們很混亂，因爲複合結構實際上是Parts，一個UML對象，它是一個類或組件的實例，名稱變得複雜等等。

  • 一般選擇一種表示法，使用球和套接字連接進行緊耦合，並且只切換到組件和提供程序之間的使用/依賴線以實現鬆耦合實際上可以切換組件（接口實現）的地方，兩者在Scott Ambler的圖1（上面鏈接）中混合，左邊鬆散，右邊緊密耦合。 UML規範在UML 2.2上層結構的第8節中也提到了這一點。

來源

2010-01-04 02:43:04

0

從VS 2010終極文檔中的下列主題：

UML組件圖中：指南：http://msdn.microsoft.com/en-us/library/dd409393%28VS.100%29.aspx

繪圖組件圖有幾個好處：

的思考您關於主要模塊的設計有助於開發團隊瞭解現有設計的 並創建一個新的。

通過將您的系統看作具有明確定義的組件集合和要求的接口，您可以改進組件之間的分離。這反過來使得設計更易於理解，並且在需求改變時更容易改變。

Component diagram http://i.msdn.microsoft.com/Dd409390.UML_CompOvReading(en-us,VS.100).png

來源

2010-02-20 03:01:49

相關問題

 相關問題