Scope
Roles are place holders for objects and agents as seen from within activities. As far as agents are concerned they coincide with UML’s “actors”, with the benefit of making the distinction with agents explicit; they are also used to describe how passive objects appear in activities. User roles describe roles with organizational responsibility, as opposed to roles played by mechanical or symbolic devices. User patterns are therefore mainly concerned with identification and authorization.
Archetypes
Roles played by objects and agents should be characterized by architecture driven stereotypes:
- Physical objects.
- Symbolic objects.
- Symbolic interactions with agents with decision-making capabilities
- Non symbolic interactions with devices
- Functions or services
- Symbolic interactions with agents without decision-making capabilities.
Those architecture driven stereotypes are associated to roles (aka actors) to make options or constraints explicit; taking example from the Home Alarm System already introduced:
- Alarms are captured by dedicated sensors for heat, sound, smoke, and intrusion. A sound siren is activated and data logged. Sprinklers are directly triggered if heat or smoke sensors are involved.
- An operator takes charge, identify the alarm(s) and read descriptors.
- Depending on the nature of emergency the firewalls comptroller and/or the scheduler service are activated.
Whereas roles are symbolic descriptions which may be associated with records, they do not describe identified agents, only their authorized behaviors. As a corollary, roles, like interfaces, can be combined and inherited without being concerned by conflicting identification mechanisms. Conflicts may nonetheless appear when roles are associated with activities.
Representation Patterns
Users are active agents with some business responsibilities. Because of those responsibilities, their identity may have to be established before authorizations can be checked. For that purpose a distinction has to be maintained between the representation of users by organization and business process on one hand, systems and applications on the other hand. The benefits of the distinction appear clearly when the basic scenarii are considered:
- Anonymous: obviously, some uses should be free of any qualification, e.g anybody can be a prospect and welcomed as such.
- Registered user: it may be necessary to keep track of users and therefore to identify them as such if and when they return. Those identities will remain strictly symbolic and mappings to actual identities will be ignored.
- Identified person: symmetrically, it may be necessary to ask for some identification document in order to establish users’ identity. Even if those identities are not managed, they can be matched to lists managed by external organizations.
- Registered person: if authorizations have to be checked, users will have to be represented as physical as well as symbolic entities.
- Registered devices: identified by events.
Given that authentication and authorization procedures fully depend on matching actual organization with system symbolic representations, the way users are represented will have direct implication on security architecture.
Authorizations
Combined with power-types the distinction between agents and roles make for straightforward modeling of authorizations. For instance, agents may take different responsibilities, each associated with different access rights.
Specialization
Users may appear in models as (1) placeholders in use cases (aka actors in UML parlance) and (2) identified agents (aka entities). Yet the semantics of specialization are different because the former stands for occurrences (specialized by subsets), whiles the latter stands for symbolic descriptions (specialized by sub-types). As a corollary, subsets of roles may overlap (e.g one dealer acting simultaneously as buyer and seller), whereas overlapping sub-types should not as they would cause identity conflicts.
The pitfalls of inheritance with UML actors can be illustrated by bank customers: given that all customers have to be identified and authorized, it is tempting to define sub-types for private and corporate customers. Unfortunately that description of actors cannot be mapped to business objects because both private and corporate users are persons while corporate customers are organizations.
That misconception appears clearly when one consider use case execution: when a user connects his status is unknown and the system can only create a nondescript instance. He has to give some id before being associated with a private customer or an employee from a corporate one.
Hence the use of the Party and Customer/Supplier patterns, with the records for orderer and order processor identified by reference to a dealer.
The Case for Abstraction
As already noted for use cases, interactions can only be triggered by concrete actors whose qualifications are to be settled during execution. In other words, a concrete actor must be defined (a) in order to be subsequently qualified once identified and authorized (b). That scenario is not possible when no concrete actor can be defined, e.g with abstract use cases (c).
