User Patterns

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.

Ghost User (J. Monk and A. Schlesinger)

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.

Roles associated with: physical object, symbolic objects, agents with authority, non symbolic devices, functions or services, symbolic devices or systems.

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.

Stereotyped roles for: IO devices, human agent, control unit, repository, service, and directly controlled devices (using No Magic).

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.

Identification 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.

  • Obviously, some uses should be free of any qualification, eg anybody can be a prospect and welcomed as such.
  • Yet, 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.
  • 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.
  • Finally, if authorizations have to be checked, users will have to be represented as physical as well as symbolic entities.

Stereotyped roles & identification patterns

Identification patterns have a direct implication for authorizations: unidentified agents should not get responsibilities since their nature (human being, animal, or device) cannot be established.

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.

Agents, Users, and Authorizations

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 subtypes). As a corollary, subsets of roles may overlap (e.g one dealer acting simultaneously as buyer and seller), whereas overlapping subtypes 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.

Semantics of inheritance are different for actors and objects.

Hence the use of the Party and Customer/Supplier patterns, with the records for orderer and order processor identified by reference to a dealer.

Roles subsets may overlap but entity subtypes should not.

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).

Actors must be concrete if their qualifications are to be established during use case execution.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

Join 303 other followers

%d bloggers like this: