Enterprise Architect＆UML：選擇界面或抽象類時的微妙之處

我目前正在從現有的C++代碼構建模型。有一個（動態加載）庫，因此必須實現/提供一個定義的接口（類）。所使用的類具有一些純虛函數，但它確實不是純粹的接口（在Java中），因爲它也是包含狀態（成員）和幾個方法實現的基類。Enterprise Architect＆UML：選擇界面或抽象類時的微妙之處

因此，它是一種混合型的 - 在C++ 現實基類，但在其主要目的的接口。

注：我不打算生成一些代碼，但模型應該是正確的文件目的。

繪製在EA（12）的例子在，一些問題就出來了：

一）有沒有喜歡的一類，並使其「抽象」（灰箱「基地」任何重要原因），還是應該直接使用工具箱中的界面（紫色框「Base2」）？到目前爲止，除了顏色之外，我無法注意到EA中的任何行爲差異。

b）我怎樣才能抑制方法背後寫的原型{abstract}？當我做而不是將它們設置爲「抽象」時，它們不是用斜體字母繪製的。但我希望他們斜體，沒有「{抽象}」。

c）有關類/接口盒的類似問題：是不是按定義抽象的接口？那麼爲什麼EA會在這裏添加{abstract}文本？將類名稱用斜體表示就足夠了。 d）我猜最左邊的箭頭（基類的泛化）和最右邊的箭頭（界面的實現）是正確的，中間的不是。對？

來源

2015-08-03 minastaros

你是誰？庫代碼的*用戶*或庫代碼的開發人員*？ - 也許你應該創建*兩個*圖。 – JimmyB

「抽象」不是刻板印象。我想知道你是如何生產的？ –

該文檔主要是出於監管原因（標準需要爲這類業務提供文檔化的軟件設計），當然，對於開發人員和我自己來說，動機是80:20。對於任何讀者來說，我知道每個選擇（抽象類/接口，有/沒有「{abstract}」都是絕對足夠的，但是因爲我剛剛開始EA來完成這項任務，所以我想從頭開始學習它在EA中，任何操作都可能對模型的另一部分造成影響，但在Visio這樣的純繪圖工具中並非如此。 – minastaros

a）取其一，但保持一致。這種差異有點深奧，除了少數不值錢的情況外（YMMV）。

二）它看起來像你的價值abstract

c）是充滿上下文/高級/多重性。接口是抽象的，如果你看一下Details選項卡，你會看到Abstract框被打勾並且不能被改變。我不知道括號內的文字來自哪裏。這不是刻板印象。我可以像這樣展示的唯一方式是將其類型從int更改爲int {abstract}。

d）你可以很好地在一個類中實現多個接口，理論上所有連接器都可以。所以Derived實現了兩個接口。

編輯作爲@minastros發現自己（和PMED我）的罪魁禍首是在EA的選項數不勝數標誌之一：

來源

2015-08-03 13:24:29

b）不，我沒有觸及多重性。在可以編輯操作的對話框中，有一個子窗口「Methods」，其中屬性「Abstract」可以設置爲「True」（或默認爲「False」）。正如我所說，如果我把它放在「假」的位置，這個方法將不會被用斜體表示。 ---謝謝你的其他答案！ – minastaros

UML允許在花括號中顯示元屬性，例如'{readonly}'和'{union}'。這可以在MagicDraw的顯示選項中打開或關閉。也許你應該看看Sparx EA的顯示選項。 –

參見http://www.iml-diagrams.org/class-diagrams.html#abstract-class – xmojmr

正如托馬斯提到，接口是一個抽象類技術，儘管抽象類並不總是一個接口。如果你甚至有一個操作（方法）沒有實現，那麼這個類就是抽象的，所以如果沒有一個操作被實現，那麼這個類也是抽象的。「抽象類」通常只被認爲是具有部分實現的類，因爲這樣的抽象類與接口不同。但是，沒有實現的類 - 接口 - 在技術上也是一個抽象類。

這可能就是爲什麼EA把{abstract}屬性放在一個接口上（它不是圖中的刻板印象，它是一個屬性 - 刻板印象使用<>）。我不會自己做，因爲它不言而喻。

來源

2015-08-10 02:57:26 BobRodes

我的主要興趣是EA是否會在我選擇「界面」或「類」符號以外的其他區別時使用，因爲基本上它們似乎是多餘的。可能我會選擇'接口'來表達更高的抽象，從而強調接口_semantic_。關於屬性 - 在手寫圖中，「{abstract}」比用斜體書寫標題更有幫助，但在PC圖中，我不想同時使用斜體名稱和屬性，尤其是對於方法（我已經找到EA中有一個設置可以禁用它）。 – minastaros

Enterprise Architect＆UML：選擇界面或抽象類時的微妙之處

回答

相關問題