UML類圖概念與規範vs實現

我正在閱讀Martin Fowler的UML Distilled。我剛剛介紹了關於類圖的部分，他在構建類圖之前強調需要對視圖進行分類。但是，我對實際繪製類圖時的實際情況略有困惑。例如，我理解理論含義會從一個角度改變協會的含義。UML類圖概念與規範vs實現

我想我的主要問題是，如果例如我像他在書中那樣對一個簡單的訂購系統進行建模，那麼類圖看起來會不同並且包含從一個角度到另一個角度的不同數量的符號。例如，從概念角度來看，我只是展示類和一些模糊的關聯及其多樣性，然後在規範視角進行建模時會包括可導航性和基本類操作和字段。

我真的很感謝這方面的一些指導，因爲我真的想更好地掌握這個主題。

來源

2011-04-28 Simon H

[用意義建模]（https://martinfowler.com/ieeeSoftware/purpose.pdf）2002年IEEE出版的John Daniels的文章發表在Martin Fowler的網站上。本文描述了概念，規範和實現模型之間的有用區別。 – 2018-02-21 05:30:51

好問題。以下是我自己經歷的一些想法;不能說馬丁是否會同意（！）但希望有用。

總之：主要區別來自關係的形式和設計選擇。

我發現下面的有用：

基本結構：大致映射到福勒的UML作爲草圖，並以交互白板上進行。主要目的是瞭解整體結構。非常非正式。特別是，關注關係只是爲了識別它們，而不是形式化 - 所以沒有基數，刪除行爲，容器類別的選擇等。
Domain Model。一個精確的模型，着重於形式化關係。具體來說，命名關聯結束，定義基數並確認刪除行爲。不考慮導航性或選擇容器類的基數> 1。我知道用於學習問題域的最好技術之一。

我幾乎總是會使用上述兩者。領域模型的關鍵之處在於使用基於動詞的命名而不是基於角色 - 因爲它描述了關係存在的原因（有效地表達業務規則：例如「一個訂單必須由一個客戶放置」）。我使用Simsion & Witt的書中描述的命名模板。

將領域模型轉換爲工作代碼需要做的工作，特別是在關係中。編程語言不能很好地支持關係，所以關聯必須被翻譯成參與類的屬性。正是在這一點上，適航性才發揮作用，以及選擇多樣性> 1的集合類型。這也是需要指定所有操作的地方。我個人覺得這種類型的圖表特別有用。域模型加上代碼給了我所需要的一切。

如果我使用可執行的UML工具，我將只使用「UML as programming language」。

道歉，如果這是一個有點散漫，希望它可以幫助...

PS：如果你想以動詞命名的一個更好的例子，我有一個post on my blog。請不要把它當作自我推銷，在這裏重複就沒有意義。

來源

2011-04-28 07:36:51 sfinnie

好久不見，感謝您在'UML tag'中的努力，您真是太棒了，希望您繼續在您的博客中撰寫關於UML和相關主題的文章。我希望我能做到這一點，但我仍然是初學者 – user2019510 2013-07-02 20:46:30

一旦他開始談論班級圖，馬丁福勒的書對我來說是廢話（例如我個人的感覺）！我同意其他圖，但類圖應該更實用，而不僅僅是高層次的設計！

它始終是相同的理論，你需要在更高的抽象層次進行建模，然後模擬你真正需要的東西。我更願意快速提供正在運行的代碼並將其顯示給客戶。從第一階段開始，我們開始進行建模，以便實現功能需求，但也包含代碼。一旦我們完成了第二階段，我們再次向客戶展示它，並再次提供UML類圖來改變需要完成的事情。經過10次迭代後，我的項目通常會完成。例如我的項目持續3至6個月。這是一個非常複雜的項目，我的客戶通常很滿意。使用Martin fowler的推薦，我的項目在12-18個月內還沒有完成，客戶肯定會感到失望。

來源

2011-04-28 08:55:13

確切地說，UML類圖只是一個符號，您可以（也應該）以不同的方式取決於您所處的軟件開發階段。您只能從類，屬性和關聯開始，然後細化圖以添加類型信息對於屬性，然後是導航，類方法，關聯的限定符......直到您獲得完整的類圖準備執行階段

請注意，您甚至可以迭代到刪除關聯並將其替換爲複雜類型的屬性具有更類似於最終實現的類圖。這取決於你如何在每個階段使用類圖。

來源

2011-04-28 10:24:41

下面是我向開發人員解釋這些想法的方法。