建模域模型

Question

我有一個涉及自動售貨機的場景，然後要求我們創建「模型問題域」。我已經非常鬆散地介紹了模型，希望有人能夠澄清這一點。

從研究看來，問題域只是一個域模型，而這個域模型又是一個UML類圖。

我見過的樣子例子他們與客戶的實體，爲了實體等等等等

幾乎數據庫模式，我只是不知道的差異究竟是什麼。

所以我只是想知道我是否在正確的軌道上，任何人都會介意闡述這一點，或者可能指向我一個簡潔的定義。謝謝。

Answer 1

「問題域」就是您感興趣的內容。就您而言，這是自動售貨機所做的所有事情，以及與之交互的人。

歸結爲一組用例，它可以在用例圖中圖示出來。自動售貨機做什麼？它需要購買者（演員）的硬幣，給予改變（也許...所以確保你理解「擴展點」），吐出東西（總是，因爲我們不在現實世界中），等等。那麼也許你可以用不同的演員來創作。維護人員拿出錢，增加變化，填充機器，運行診斷堆棧，不管。其中每一個都是一個用例。把它們放在一個用例圖中。

如果您想詳細瞭解每個用例的用途，請使用活動圖。每個用例一個。

Answer 2

任何系統（軟件或不軟件，是否建模）都有結構和行爲方面的內容。

結構方面是系統的非時間約束方面，比如系統由哪些類組成，它們的關聯和依賴關係，它們如何劃分爲子系統等。大多數這些元素通常被稱爲作爲分類器。

行爲方面顯示了這些結構是如何一起合作一段時間來實現系統的目標，如方法，狀態機，工作流程，用例實現等

的結構和行爲方面是什麼您可以指定何時編寫代碼或創建模型。

對象，根據定義的類的實例。這意味着對象是系統執行時實際存在的「事物」。因此，你不編程一個對象;你編寫一個類，它在執行時被實例化爲一個或多個對象。但是，在許多建模語言中（但在編程語言中並不常見），您還可以對場景的規範建模，該場景顯示對象的規範以及它們如何交互，例如在UML中，您可以創建一個對象圖，顯示一個在執行過程中如何構造和協作對象系統（即實例化類）的例子。

現在，系統總是努力爲其周圍實現一個或多個目標。周圍是由與系統交互的人員和/或其他系統（演員）組成。系統所處的位置和意義所在的「周圍」或「背景」通常稱爲「域」。

這些「演員」有一個他們希望系統幫助他們解決的「問題」。在對這個問題進行建模時，可以將該模型稱爲系統的「問題域模型」。它指出了問題領域的邏輯結構和行爲方面，沒有說明如何在特定的系統實現中實現它。也就是說，它不是指Java，SQL，主鍵，事務，反射，角度等實現方面;而是側重於域的核心結構，如訂單，合同，合同，產品等。

問題域模型是系統開發人員和支付人員之間最重要的「合同」之一系統或作爲系統的所有者和用戶。它使你能夠以相同的方式理解要解決的問題，並確保你們都使用相同的概念來推理它。按照定義，因爲它不是一種技術手段，所以應該儘可能使用簡單的表示法（但仍然嚴格清晰）來描述它，以便非軟件專業人員能夠理解並達成一致。類圖（從所有技術細節中去除）和用例圖是可用的兩種符號技術。而且對象圖和活動圖也可以派上用場。

如果您對此感興趣，我將在Udemy的高級概念領域建模課程中提供一門課程。這裏是鏈接和90％關代碼：https://www.udemy.com/get-your-concepts-straight/?couponCode=CONCEPTS29

問候 每