關於UML的問題「抽象」和定型

Question

喜逢身體我試圖瞭解UML，但也有它

一些問題在UML什麼是標記一類的刻板印象<<abstract>>的意義是什麼？

以及如何表達這種約束是不變的，

Answer 1

刻板印象「抽象」不存在 - 一個抽象類，應使用斜體字描繪。抽象意味着一個類不能被實例化。它需要一個子類來完成。因此，作爲一個僞碼的約束，這將意味着

for all instances i of MyAbstractClass holds: i.actualClass != MyAbstractClass 

或OCL爲MyAbstractClass持有

self.allInstances()->forAll(i: MyAbstractClass | i.classifier <> self) 

因爲這個詞「抽象」是不會顯示在你的第一個問題版本，我擴大了一般的定型：

首先：在學習UML時，刻板印象不應該是你研究的第一件事。他們相當複雜。 （<<MyStereotype>>）不具有一般含義。它是由具體的刻板印象定義的。通常情況下，您不能將刻板印象作爲不變量來表達。

但是UML的一些其他方面也可以用同樣的方式顯示：即使UML Metalevel中的類沒有原型，甚至是不同的實際類型，它也會被標記爲<<metaclass>>。刻板印刷本身帶有<<stereotype>>標記（即使它們是特殊類別的實例）。

定製原型的示例可以是「服務」。您可以標記代表服務的類。可能有一個限制，告訴你一個「服務」必須實現一個特殊的接口。在這種情況下，您可以將此約束表達爲（無聊）不變量。但可能它甚至只是一個標記。在後一種情況下，您可以使用關鍵字作爲替換。

Answer 2

我意識到這個線程已經有兩三年的歷史了，但是當它被別人引用時，我意識到這一點，因爲支持斷言UML規範不支持«abstract»構造型。這個說法不太準確，我想解釋一下爲什麼。我將首先澄清什麼是抽象類。

抽象類是不包含完整實現的類的定義。因此，抽象類不能直接實例化;他們必須是專門的（繼承）。抽象類通過斜體表示類名和抽象方法來表示，另外還可以通過給類名和/或操作添加一個{abstract}屬性（方法，我們通常會說，但方法實際上是「方法「執行該操作的操作）是抽象的。

接口是沒有實現的抽象類;他們的符號不同於其他類型的抽象類（不要斜體，使用«interface»關鍵字，並用虛線表示所有專業化箭頭）。所以，正如克里斯蒂安在這裏所說的那樣，抽象類有標準符號 - 至少在類圖中是這樣。

現在，雖然它是真實的，基督教也表示，該«abstract»刻板印象不存在，這也是事實，你可以創建它，如果你想和這樣做是在UML規範的支持。你不可能有理由（至少在課堂上），但你仍然可以。

構造型是UML的「可擴展性機制」（有三種：構造型，標記值和約束）。它允許你更具體地定義某種元素。定型適用於類（實際上是元類，元類是其實例也是類的類）。一些刻板印象是預先定義的「標準刻板印象」（在UML 1.4中它們被稱爲「標準元素」）。這些例子是«metaclass»（同樣，一個類的實例也是類）和«file»（開發系統的上下文中的物理文件）。

陳規定型是一種關鍵字。該規範（上層建築 2.0，附錄B，P 663）具有這樣說關鍵字：

UML關鍵字是保留字屬於UML 符號的一個組成部分，並且通常顯示爲附加的文本註釋到UML 圖形元素或作爲UML圖中文本行的一部分。這些 單詞......不能用於命名用戶定義的模型元素，其中這樣的命名會導致對模型的模糊解釋 。例如，關鍵字「跟蹤」是系統定義的抽象的刻板印象（見附錄C，「標準刻板印象」），因此，不能用於定義任何用戶定義的刻板印象。

在UML，關鍵字被用於四個不同的用途：

• 爲了區分從其他人共享相同的一般圖形形式的特定UML概念（元類）...

• 爲了區分UML概念（元關聯）與其他關係共享相同的一般圖形形式之間的特定類型的關係...

• 要指定附加到UML概念的某些修飾符的值T（元屬性值）...

• 要指定標準刻板印象（見附錄C，「標準定型」）...

關鍵詞總是封閉在guillemets（«關鍵字» ），它們作爲視覺線索更容易地區分關鍵字的使用時間......除了識別關鍵字外，guillemets還用於區分在用戶配置文件中定義的原型的使用。這意味着：

1. 不guillemets之間出現的所有單詞都一定的關鍵字（即，保留字），和
2. 詞語出現在guillemets並不一定代表定型。

換句話說，只要不是關鍵字，您就可以創建任何想要的構造型。由於「抽象」不是關鍵字，因此可以創建一個«abstract»原型。爲了做到這一點，然而，你將不得不在UML 2.0及以上版本中遇到一些麻煩，比在UML 1.4中更麻煩。 UML 1.4簡單地指出，刻板印象是UML規範的擴展機制。人們可以簡單地定義刻板印象，將其應用於想要的任何UML元模型部分，並記錄變化。 UML 2.0希望將原型與UML元類的關係正式化（UML圖中的任何項目都是元類，並且是UML元模型的一部分）。所以，他們想出了Profiles。此示例圖顯示的配置文件是如何工作的：

現在，黑色箭頭可能看起來有點奇怪，因爲你沒有看到它在任何情況下，但是這一個。 UML 2.0引入了擴展的概念，它將其定義爲「用於指示元類的屬性通過刻板印象擴展。」這個黑色箭頭表示一個擴展名。我會引用湯姆彭德（UML聖經，威利出版社，2003年）對這張圖的解釋，因爲他做的比規範更好（我當然不能改進）：

它顯示了一個組件被一個Bean構造型擴展，這是必需的。 Bean原型是一種抽象類型，具有兩個子類型 - 實體和會話。因此，Component的每個實例都必須通過Entity構造型或Session構造型的實例進行擴展。請記住，構造型是一種可以具有屬性的類 - 在這種情況下，Session構造型具有名爲state的屬性。這對應於一個標記的定義，其值指定了Session的狀態。標記值是一個枚舉StateKind，它具有無狀態值或有狀態值。

組件對它有約束，顯示在附加到組件符號的註釋中，該註釋聲明組件不能一概而論，或者專用於組件。

該圖還顯示了Interface元類由Remote和Home構造型擴展。 EJB包中有一個約束，顯示在包中的註釋中，表明Bean必須實現一個Home接口。

因此，如果您有理由去創建它，那麼確實可以使用«abstract»刻板印象。任何人都希望在除了類圖之外的某個地方表示抽象類的主要原因。