角色模式
上圖定義了乙個交換機（switch）和乙個路由器（router），二者作為物理裝置（physicaldevice）的子類（繼承方式）。交換機和路由器的基本區別是前者**流量，後者路由並**流量。但是對於一台具有路由功能的三層交換機如何處理呢？一種可能的方式是在上圖中為交換機（switch）建立乙個子類layer3switch。但這是乙個不好的方案，因為每當路由技術更新換代時，這個模型中的路由器（router）和三層交換機（layer3switch）都隨之需要更新；另外這種方案中的三層交換機與路由器並沒有多大區別。如果出現了四層交換機（layer4switch），那麼又如何為之建模呢？路由器、layer3switch和layer4switch的路由型別又如何區分呢？如何處理帶有防火牆功能的路由器呢？類似的問題是很多的。可見，多重繼承的方式並不能解決這類問題。
對於以上問題，我們可以採用一種更加優雅的方式解決——角色模式。
角色模式是增強模型可擴充套件性的基本方式。角色模式將乙個實體的各種功能抽象為不同的物件，而不是將其功能嵌在實體本身中，例如角色模式可以將乙個裝置的不同功能抽象為不同的物件。
乙個角色刻畫了乙個物件所能提供的功能。從sid的業務檢視角度看，這種刻畫指的是屬性和關係；從sid系統檢視看，這種刻畫擴充套件為方法、約束和行為。
角色模式的好處是：
1、易於分別定義實體本身的行為與實體的功能而互不影響；
2、實體角色的改變不需要改變實體本身。
回到一開始講到的例子，如果採用角色模式，我們不需要定義不不同的子類，而是為裝置的不同功能建立不同的角色，這樣就解決了同樣的功能重複出現在不同裝置上的混亂情況，例如可以將路由功能與路由器、三層交換機進行關聯。如下圖所示：
由於通訊網技術的不斷發展，繼承方式不能很好地駕馭這些變化。如果將關鍵功能抽象為角色，則可以為現在和將來出現的裝置統一建模，因此將裝置角色（devicerole）定義為不同於裝置（device）的實體是一種可擴充套件的方式。這樣只需要為裝置角色（devicerole）建立不同的子類以表示不同的功能，通過組合相關的裝置角色形成某個裝置的功能，從而避免為裝置（device）建立子類。
角色模式的應用：資源配置
舉乙個mpls vpn的例子，不管vpn的拓撲有多複雜，其裝置基本上由3種角色的路由器構成：
1、 ce
2、 pe
3、 p
乙個基本的vpn拓撲如下圖所示：
上圖顯示了2條vpn，紅色vpn通過骨幹網連線了站點1和站點3，綠色vpn通過骨幹網連線了站點2和站點4。這2條vpn共享了相同的網路。角色的概念可以用來標準化ce與pe的連線和**配置。例如，為ce路由器定義一組策略，用於控制其如何連線不同型別的pe路由器。這些策略可以抽象為不同的角色，獨立於任何特定的裝置，從而能夠減少冗餘並實現重用。另外，運營商骨幹網的核心由扮演p角色的路由器構成，由於這4個p路由器功能相同，其中1個路由器的配置模板可以用來配置其它3個p路由器。pe和ce的配置可以採用相同的方式。
oracle中的角色
oracle 中的角色 一 何為角色？我在前面的篇幅中說明許可權和使用者。慢慢的在使用中你會發現乙個問題 如果有一組人，他們的所需的許可權是一樣的，當對他們的許可權進行管理的時候會很不方便。因為你要對這組中的每個使用者的許可權都進行管理。有乙個很好的解決辦法就 是 角色。角色是一組許可權的集合，將角...
oracle中的角色
一 何為角色？我在前面的篇幅中說明許可權和使用者。慢慢的在使用中你會發現乙個問題 如果有一組人，他們的所需的許可權是一樣的，當對他們的許可權進行管理的時候會很不方便。因為你要對這組中的每個使用者的許可權都進行管理。有乙個很好的解決辦法就是 角色。角色是一組許可權的集合，將角色賦給乙個使用者，這個使用...
Scrum中的角色
在scrum中有三個基本的角色 產品所有者 product owner 開發團隊和scrummaster。產品所有者負責取得產品最大的商業價值，收集相關於產品的所有資訊 從客戶或產品的終端使用者，開發團隊成員和專案管理者中獲取並將資訊轉化為優先權專案列表。在一些情況下，產品所有者正是客戶本人 在另一...