Roles represent a fundamental way to provide extensibility in the model. The Role Object pattern [ROLEOBJ] is used to extend the use and application of an object. For example, by modeling the different functions that a device can play as a set of objects.<br/>A role characterizes the function that a particular object plays. In the SID, the characterization may be to specify attributes and relationships.<br/>Roles provide an extensible means of abstraction that enables the user to model the functions played by an entity as separate objects (instead of embedding that functionality in the entity itself). For example, suppose that you are modeling the business functions that your employees have. Basic organizational boundaries define some behavior (e.g., marketing vs. sales vs. engineering), but often employees play multiple roles (e.g., an engineer that has sales support functions). This phenomenon doesn’t just occur for people – other managed objects exhibit it as well. For example, in a VPN, some DeviceInterfaces talk to a customer, while others never touch a customer.<br/>In general, managed objects don’t all have the same behavior, but different managed objects may have some common behavior. Worse, an object might exhibit more than one set of common behaviors, or may take on and remove different behaviors during its lifetime. Thus, we need a means to capture these and related cases. A set of role patterns provide an extensible and straightforward means of accomplishing this goal.<br/>Before these different role patterns are discussed, it is important to differentiate between an instance or a type. Asking an object if it is an instance of type is something different than asking it if it is an instance of a class, since the types (interfaces) and the classes (implementations) can be different. (Note that there are patterns to accomplish this function.)<br/>The SID is concerned with types, not implementation.<br/>There are five types of role patterns that are extensions of [ROLEOBJ], described as follows:<br/><ul>
<li>Single Role Type. This pattern combines all of the features of different roles into a single type, and is most useful for modeling objects having a few variations on the same basic behavior.</li></ul>
<ul>
<li>Separate Role Type. This pattern models each role as its own separate type, and is most useful for modeling objects that have little if any common behavior.</li></ul>
<ul>
<li>Role Subtype. This pattern models each role that exhibits different behavior as a subtype. Note that this does NOT mean that sub-classing is used, as this is an analysis pattern and is thus concerned with interfaces, not implementation. This pattern is all about maintaining the illusion that clients are dealing with a single object that has multiple, changeable types.</li></ul>
<ul>
<li>Role Object. This pattern models each role that exhibits different behavior as a separate object. The separate role objects are then related to a single base object that ties the different behaviors together. This pattern is used when maintaining the illusions of a single object is too difficult, or doesn’t supply the correct semantics.</li></ul>
<ul>
<li>Role Relationship. This pattern models each role as a relationship with an appropriate object.</li></ul>
Of these five patterns, the SID uses the fourth – Role Object – almost exclusively. Single Role Type and Role Type aren’t used because they best deal with behavior which is not included in the SID.<br/>This leaves Role Subtype and Role Relationship. The problem with the Role Subtype pattern (in the context of the SID) is that this pattern cannot be used if there are multiple and/or changing roles.<br/>The Role Relationship pattern is not used in the SID due to its complexity. This pattern is very well suited when the role itself embodies a relationship between a base object and some other object (usually a group). For example, consider an organization which requires new employees to spend an equal amount of time working for multiple departments. In this case, the role binds the person to the particular organization that he or she is currently working for. Thus, it is best modeled as a relationship between the person and the organization that the person is working for.<br/>Figure below shows a simplified view of the concepts of using the Role Object pattern.<br/>The figure shows that an Individual (or an Organization) can be assigned zero or more roles. Thus, an Employee can take on the roles of ServiceProvider and Partner.<br/>The idea is to define the functionality that a business entity can play as a set of subclasses of EntityRole, and then associate the specific functionality that is desired using the EntityHasRoles aggregation. This enables the functionality and behavior of the business entity to be easily customized. For example, consider two different people working in the same department – both interact with a customer, but Bob is a manager and Joe isn’t. Rather than add employee-specific attributes to the definition of a Person, a Person can be kept general, and employee-specific attributes can be added to an appropriate role.<br/>More formally, roles recognize the fact that different entities may have different roles that it can play when it collaborates with other entities in the system. Separating this into different roles enables behavior to be defined that involves just the role, as opposed to all of the attributes of the entity. This enables the communication to become more specific and thus easier to generalize.<br/><b>Different Types of Roles in SID</b><br/>The SID is unique, in that roles are used in the vast majority of its domains, to ensure that the above philosophy is applied wherever it makes sense. Three different examples that show the diversity of roles in the SID are as follows:<br/><ul>
<li>Party and PartyRole (Party addendum). Party is a superclass for modeling people and organizations, and PartyRole is a superclass for modeling the different jobs that people can have.</li></ul>
<ul>
<li>Resource and ResourceRole (Physical Resource addendum and Logical and Compound Resource addendum). Resources are physical, logical, and compound resource entities that represent the definition, development, and operational aspects of the information computing and processing infrastructure of a system. There are PhysicalResourceRoles as well as LogicalResourceRoles, which enable functions associated with the physical and logical aspects, respectively, of a resource to be modelled independent of that resource. There are also CompoundResourceRoles, which enable roles to be assigned to CompoundResources (Resources that contain one or more PhysicalResources and LogicalResources).</li></ul>
<ul>
<li>Service and ServiceRole (Service Overview addendum and Quality of Service addendum). Services represent intangible functionality that is provided by the information computing and processing infrastructure of a system. CustomerFacingServiceRoles represent abstracted functionality that represent how a Product is realized, while ResourceFacingServiceRoles represent abstracted functionality that are required in order for the CustomerFacingService to function correctly.</li></ul>
All of these are currently defined in various GB922 Addenda as noted above.<br/>