UML中的構造型和類繼承有什麼區別？

Question

我對UML中「刻板印象」和「超類」之間的區別感到困惑。

比方說，我想創建涉及圖「WidgetMaker」。 WidgetMaker顯然是一個Actor所以UML標準是其原型演員：

<<Actor>> WidgetMaker 

但我在Java /紅寶石/ C++世界裏成長起來的編程。在這個世界中，關係是：

class Actor 
end 

class WidgetMaker < Actor 
end 

，看起來像這樣在UML：

Actor 
    ^
    | 
WidgetMaker 

所以我的問題是：爲什麼UML必須在所有的時候，你可以很容易地模擬這些概念定型使用類繼承，它也了。

一旦我們有更多的演員的「種」，這個問題就顯得比較令人費解：

   Actor 
       ^
       | 
    ------------------------ 
    |   |   | 
    Person  Robot  Group 
    ^
    | 
WidgetMaker 

與

<<Actor>> <<Person>> WidgetMaker 

Answer 1

一個刻板印象是存在的，用來呈現了有關工件的更多信息，其中文檔或將其分類爲特定的工件塊可能不會給出。例如，你已經確定了一個數據類，你可以給它起個名字，解釋它的屬性和操作，但是它本身可能不會提供完整的信息。當你把它定型爲<>時，它指定了完整的信息;在此之前，它像任何其他類一樣繼續發展。

「刻板印象是用來擴展UML符號元素，分類和擴展協會，繼承關係，類和組件」

刻板印象提供了創建新的造型元素的能力。定型必須基於屬於UML元模型的元素。一類常見的刻板印象是實體，邊界，控制，效用和例外。類別的刻板印象顯示在包圍在guillemets中的類名下（即«和»，發音爲gee-may）。如果需要，圖形圖標或特定顏色可能與刻板印象相關聯。

Answer 2

據我瞭解，定型的主要目的是使UML自身的擴展名（作爲建模語言），而不是來建模。

話雖如此，我也認爲你的問題暗示另一種可能有效的答案：有些人喜歡使用定型指定類之間的某些共性（非正式！）。他們可能會這樣做，僅僅是因爲它比子類更容易，對於模型的目的來說「足夠好」。

例如，許多軟件系統具有表示所謂的域實體類（如公司，客戶，訂單，產品等東西）。最終，你可能想要有一個像Entity共同類派生Company,Customer等。但是，最初只需使用這些刻板印刷類即可，如<<Entity>> Company,<<Entity>> Customer等。從本質上講，這只是建模工作的便利（以及成本/收益！）的問題。

Answer 3

在你的示例中，Actor可能不需要作爲類來實現，但這可能不總是如此。刻板印象是可以應用於大多數UML元素而不僅僅是類的抽象。

它們封裝了語義，並不意味着如何提供這些語義。另一個例子可能是一個通信通道，它們被定型爲HTTP或RPC。他們正在與讀者溝通如何提供某些內容，而不會使模型複雜化，造成不必要的細節。

UML規範提供了一些預定義的構造型，但它們的實際功能來自於能夠通過配置文件定義自己的構造。您可以將一個域對象標記爲一個EJB來保存自己指定的所有鍋爐板代碼。

Answer 4

OMG如何將它們應用於SysML或BPMN配置文件中，可以很好地說明定型背後的意圖。具體來說，構造型將一組新的建模結構描述爲用於指定您的域的語言的一部分。例如，SysML中的Block是應用於Class的原型。它帶來了一個用於系統工程的類的定製。在這種情況下，它取代了Class的使用並建立了與其他元素和圖類型的新關係，例如，塊< <滿足>>要求（允許的關係）或塊可以使用內部框圖（允許的行爲）建模。 刻板印象不用於模擬您的主題空間。它將建模的使用分類爲系統定義的垂直或水平方面。

Answer 5

通過指定例如UML元模型，構造型擴展了UML元模型的結構。 UML模型中元素的特定於域的屬性，並且不會改變正在建模的系統的運行時語義 - 它們只是豐富了建模語言。

這是一個很好的例子，它在設計模式圖中給類賦予「角色」。類的功能在類中給出，而不是由刻板印象添加 - 這支持上述語句。

現在，棘手的部分是繼承或定型類;根據UML 1.3，它們不是可繼承的;然而，通過某種刻板印象給「A」級的限制也適用於專門課。在我看來，這仍然不適用於運行時，所以語義層面仍然存在歧義。更多在this mail thread。