•An OperationalPerformer performing (in context) an OperationalActivity.
•An OperationalResource performing (in context) a Function.
•A ServiceSpecification performing (in context) a ServiceFunction.
The PerformsInContext (Role) relationship forms an explicit join relationship, within which you can specify the conditions and rules under which the OperationalPerformer performs the OperationalActivity.
In DoDAF 2’s metamodel (DM2) – the ActivityPerformedbyPerformer relationship was alias Role. Although the UAF specification nominally suggests ActivityPerformedbyPerformer is replaced by IsCapabletoPerform, and that Role (an instance of a Performer) PerformsInContext OperationalActivity – for a non-UML implementation, ActivityPerformedbyPerformer is replaced by PerformsInContext – since it describes unambiguous action, and conditions under which the activity is performed.
In layman’s terms, a Role is defined by a Performer performing an Activity. For example, a Person (OperationalPerformer) who is Developing Code (OperationalActivity) is performing the Role of Developer. That same Person providing Training to Customers is performing the Role of Trainer. That same Person writing a data sheet on the product is performing the Role of Marketer. That same Person demonstrating the product to a Customer in order to sell it, is performing the Role of Seller, and so on.
Essentially, the Role in DoDAF 2’s DM2 (and System Architect’s implementation of UAF) is different than a UML-based implementation in that to specify a Role in DM2 and System Architect, you must specify the Performer and the Activity being performed; in UML you can specify a Role without the Activity (as in UML, a Role is mapped to a software concept that it is an Object that instantiates a Class).