圖 3：這里額外的區顯示Order組件提供和要求的接口。
在圖 3 中的Order組件例子中，組件提供了名為 OrderEntry 和 AccountPayable 的接口。此外，組件也要求另外一個組件提供Person接口。3
組件接口建模的其它方法
UML 2 也引入另外一種方法來顯示組件提供并要求的接口。這個方法是建立一個里面有組件名的大長方形，并在長方形的外面放置在 UML 2 規范中稱為接口符號的東西。這第二種方法在圖 4 中舉例說明。
圖 4: 一種可選擇的方法（與圖3相比）：使用接口符號顯示組件提供/要求的接口
在這第二種方法中，在末端有一個完整的圓周的接口符號代表組件提供的接口 -- “棒棒糖”是這個接口分類器實現關系符號的速記法。在末端只有半個圓的接口（又稱插座）符號代表組件要求的接口（在兩種情況下，接口的名字被放置在接口符號本身的附近）。即使圖 4 看起來與圖 3 有很大的不同，但兩個圖都提供了相同的信息 -- 例如，Order組件提供兩個接口：OrderEntry 和 AccountPayable，而且Order組件 要求 Person接口。
組件關系的建模
當表現組件與其他的組件的關系時，棒棒糖和插座符號也必須包括一支依存箭頭（如類圖中所用的）。在有棒棒糖和插座的組件圖上，注意，依存箭從強烈的（要求的）插座引出，并且它的箭頭指向供應者的棒棒糖，如圖 5 所示。
圖 5：顯示Order系統組件如何依賴于其他組件的組件圖
圖 5 顯示，Order系統組件依賴于客戶資源庫和庫存系統組件。注意在圖 5 中復制出的接口名 CustomerLookup 和 ProductAccessor。 在這個例子中，這看起來可能是不必要的重復，不過符號確實允許在每個依賴于實現差別的組件中有不同的接口（和不同的名字）（舉例來說，一個組件提供一個較小的必需的接口子類）。
子系統
在 UML 2 中，子系統分類器是組件分類器的一個特別版本。因為這一點，子系統符號元素象組件符號元素一樣繼承所有的組件符號集規則。唯一的差別是，一個子系統符號元素由subsystem關鍵字代替了component，如圖 6 所示。
圖 6：子系統元素的一個例子
UML 2 規范在如何區別子系統與組件方面相當含糊。從建模的觀點，規范并不認為組件與子系統有任何區別。與 UML 1. x 相比較，這個 UML 2 模型歧義是新的。但是有一個理由。在 UML 1. x 中，一個子系統被認為是一個軟件包，而且這個軟件包符號正對許多 UML 實踐者造成困惑；因此，UML 2中把子系統作為特殊的組件，因為這是最多的 UML 1. x 使用者了解它的方式。這一改變確實把模糊引入圖中，但是這一模糊更多的是 UML 2 規范中對抗錯誤的一個現實反射。
到這里，你可能正在抓著頭皮并感到疑惑，什么時候該用組件元素，什么時候又該用子系統元素。相當坦率地說，我沒有一個直接的答案給你。我可以告訴你，UML 2 規范中說，何時該使用組件或子系統決定于建模者的方法論。我個人很喜歡這個答案，因為它幫助確保UML與方法論相互獨立，這在軟件開發中將幫助保持它的普遍可使用。
超越基礎
組件圖是比較容易理解的圖之一，因此沒有很多超越基礎的內容。然而，有一個方面你可以認為是略微困難的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
